representation and evaluation of security policies for distributed system services
Download
Skip this Video
Download Presentation
Representation and Evaluation of Security Policies for Distributed System Services

Loading in 2 Seconds...

play fullscreen
1 / 25

Representation and Evaluation of Security Policies for Distributed System Services - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

Representation and Evaluation of Security Policies for Distributed System Services. Presentation By Girija Gavankar. Outline. Abstract, Motivation Framework Policy Language,generic conditions EACL, EACL Rules and Evaluation, Credentials GAA-API Approach GAA-API components Conclusion

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Representation and Evaluation of Security Policies for Distributed System Services' - urvi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
representation and evaluation of security policies for distributed system services

Representation and Evaluation of Security Policies for Distributed System Services

Presentation

By

Girija Gavankar

outline
Outline
  • Abstract, Motivation
  • Framework
  • Policy Language,generic conditions
  • EACL, EACL Rules and Evaluation, Credentials
  • GAA-API Approach
  • GAA-API components
  • Conclusion
  • Status
abstract
Abstract
  • A New Model for Authorization that integrates both Local and distributed access control policies.
  • This model is also extensible across applications and administrative domains.
  • Introduces a general mechanism which can implement several security policies including

- ACLs - Role-based access control

-Capabilities - Lattice-based access control

  • Thus can be useful in Grid infrastructure.
motivation
Motivation
  • User needs to be authenticated
  • Restrictions on granted access and resources
  • Customization of policies
  • Enforcement of policies

Domain A

Domain B

Request for resource

database

Security Policy A

Security Policy B

framework
Framework
  • Designed such that it applies to a distributed system that spans multiple autonomous domains without central management authority
  • Components of the Architecture

- Authentication Mechanism

- Group Server

- GAA- API

- Delegation support

outline6
Outline
  • Abstract, Motivation
  • Framework
  • Policy Language,generic conditions
  • EACL, EACL Rules and Evaluation, Credentials
  • GAA-API Approach
  • GAA-API components
  • Conclusion
  • Status
policy language
Policy Language

Example :: Joe and members of department-1 can can print documents on Monday through Friday 9:00 AM to 6:00 PM

  • Security policy associated with a protected resource consist of

- a set of allowed operations,

- a set of approved principals and

- optional constraints

  • But to specify conditional restrictions on the access rights, the traditional ACL and capability abstractions must be extended
  • To implement a policy, we should be able to define

- access identity - a set of access rights

- grantor identity - a set of conditions

policy language8
Policy Language
  • Policy language is represented by a sequence of tokens, each token has

- Token type

- Defining Authority

- Value

Example :

Specifying Access Identity Specifying Access rights

Token Type:access-user-id

Defining authority: KerberosV5

Value :[email protected]

Token Type :Pos-access-rights

Defining Authority:Local Manager

Value :FILE:read,write

generic conditions
Generic conditions
  • Time
  • Location (host/domain/networks)
  • Message protection constraints (confidentiality,Integrity)
  • Connection (Security of connection,BW)
  • Multi-level security constraints (lattice-based)
  • Privilege constraints (clark-wilson)
  • Payment(must be paid prior to access)
  • Quota(a currency and a limit)
  • Strength of authentication (set of authentication Mech.)
  • Attributes of subjects(subject must have set of attributes )
slide10
EACL
  • Extends the conventional ACL concept by allowing on to specify conditional authorization policies
  • Implemented as conditions on authentication and authorization credentials

Token Type:access-id-GROUPDefining Authority:DCEValue:15

Token Type:pos-access-rights Defining Authority:local-manager Value:FILE:read FILE:write

Token Type:location Defining Authority:system-managerValue:*.USC.EDU

eacl rules and evaluation
EACL Rules and Evaluation
  • A single EACL does not specify both –ve and +ve rights
  • If both are allowed in group entries, then the inconsistencies are solved by ordered interpretation
  • The authorization that has already been examined takes precedence over new Authorizations
  • Ordering Approach :

- easier to implement

- requires total ordering

- needs careful writing of EACL by administrator

- thus error-prone

credential evaluation
Credential evaluation
  • May contain optional conditions associated with the granted rights
  • Example : Tom connecting from ORG.EDU to write to doc.txt at 5pm.
  • Following are the EACLs associated with doc.txt

Identity credential:

access-id-USER kerberos.v5 [email protected]: time-window pacific-time zone 6am-7pm

Group membership credential:

access-id-GROUP kerberosV5 [email protected]: privilege:restricted

Delegation credential:

grantor: grantor-id-USER kerberosV5 [email protected]: access-id-USER kerberosV5 [email protected]: doc.txtrights: pos-access-rights local-manager FILE:writecondition: location local-manager *.org.edu

outline13
Outline
  • Abstract, Motivation
  • Framework
  • Policy Language,generic conditions
  • EACL, EACL Rules and Evaluation, Credentials
  • GAA-API Approach
  • GAA-API components
  • Conclusion
  • Status
approach
Approach
  • Local policies: ACLs
  • Distributed policies: credentials
  • An optional condition field is added to ACLs(EACL) and credentials

- conditions in credentials are evaluated in addition to the conditions in the matching ACL entries

  • Generic Authorization and Access control API (GAA API)
  • - gaa_get_object_acl
  • - gaa_check_authorization
  • GAA API Security Context
approach contd
Approach contd…

5

5a

GAA-get-object-ACL

Application

6

EACL

1

4

GAA-check-Authorization

7

6b

Security API

(1, 2, 3, 4, 4a) request and verification of principal’s identity

4a

6a

2

3

(5, 5a) call to the gaa_get_object_acl, retrieval of appropriate EACL

GAA- API Security Context

Security Server

(6, 6a, 6b) call to the gaa_check_authorization

(7) GAA API answer

gaa get object acl
GAA_get_object_acl
  • gaa_get_object_acl (

minor_status, // OUT, mechanism-specific status code

object, // IN, reference to the object to be accessed

authr_db, // IN, pointer to application-specific authorization database

retrieve, // IN, upcall function for the retrieval of the object ACL

acl_handle // OUT, handle to the ACL, which is a subject of examination)

gaa check authorization
GAA_check_authorization
  • gaa_check_authorization (

minor_status, // OUT, mechanism-specific status code

sec_context, // IN&OUT, principal\'s security context

acl_handle, // IN, handle to ACL, which is a subject of examination; returned by the gaa_get_object_acl

check_access_rights, // IN, OPTIONAL, list of access rights for authorization

gaa_options , // IN, OPTIONAL, describes the behavior of the GAA API

gaa_answer , // OUT , contains various information for further evaluation by an application )

gaa api gaa answer
GAA API gaa_answer
  • struct gaa_answer_struct {

valid_time, // time period during which the authorization is granted

granted_access_rights, // granted access rights

conditions, // conditions on the granted access rights

required_sec_attributes // information about additional security attributes required

}

gaa error code
GAA Error Code
  • GAA_AUTHORIZED
  • GAA_NOT_AUTHORIZED
  • GAA_ADDITIONAL_CHECKS_REQUIRED
gaa security context
GAA security context
  • struct gaa_sec_context { identity_cred // identity credentials

authorized_cred // delegated credentials, capabilities

group_memb // grantee is a member of listed groups

group_nonmemb // grantee is NOT a member of listed groups

attributes // miscellaneous attributes attached to the grantee

unevaluated_cred // unevaluated credentials

connection_state // per-connection context

condition_evaluation // evaluate application-specific conditions

pull_cred // obtains the necessary credentials

cred_evaluate // parse the acquired credentials }

conclusions
Conclusions
  • Extending ACLs with “Conditions” allows flexibility in distributed Authorization mechanism
  • extensible across multiple applications supporting different operations and different kinds of protected objects
  • The problem of policy translation is resolved by providing generic evaluation functions
  • Currently integrated with Prospero Resource Manager

and Globus Security Infrastructure

status
Status
  • Current Prototype

- uses Kerberos

- evaluation of identity credentials

  • Future Work

- refining evaluation algorithm

- evaluation of other types of credentials

- requesting additional credentials and evaluation

of acquired ones

clark wilson
Clark-Wilson
  • Developed to address security issues in commercial Environment.
  • 2 categories to realize integrity :

- Well-Formed transactions

- Separation of duty

  • Thus to integrate with GAA- API,

-Represent a constraint that only trusted programs can modify objects,

“application:Checksum ” OR“application:endorser” (valid certificate required)

  • For Dynamic separation of duties,

“Privilege:restricted”– only one group at a time”

lattice based policies
Lattice-based Policies
  • Madatory Confidentiality and Integrity
  • Objects as well as subjects assigned labels as follows,

- Confidentiality Labels :Top-secret/NASA

- Integrity Labels :High- Integrity, Low-Integrity

  • To prove eligibility to access an object, a subject has to present a valid credential, stating subject\'s security label
  • Eg. Conf-read-equal:confidentiality-label

(subject must have equal clearance as to the conf-label)

ad