Representation and Evaluation of Security Policies for Distributed System Services

1
Representation and Evaluation of Security
Policies for Distributed System Services

• Presentation
• By
• Girija Gavankar

2
Outline

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

3
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.

4
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
5
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

6
Outline

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

7
Policy Language
Example Joe and members of department-1 can
can print documents on Monday through Friday 900
AM to 600 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

8
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 girija_at_usc.edu
Token Type Pos-access-rights Defining
AuthorityLocal Manager Value FILEread,write
9
Generic conditions

• Time
• Location (host/domain/networks)
• Message protection constraints (confidentiality,In
  tegrity)
• 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 )

10
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-GROUP Defining Authority
DCE Value 15 Token Type pos-access-rights
Defining Authority local-manager Value
FILEread FILEwrite Token Type location
Defining Authority system-manager Value
.USC.EDU
11
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

12
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
tom_at_ORG.EDUcondition time-window pacific-time
zone 6am-7pm Group membership credential
access-id-GROUP kerberosV5 admin_at_ORG.EDUconditio
n privilegerestricted Delegation credential
grantor grantor-id-USER kerberosV5 joe_at_ORG.EDU
grantee access-id-USER kerberosV5 tom_at_ORG.EDU
objects doc.txtrights pos-access-rights
local-manager FILEwritecondition location
local-manager .org.edu
13
Outline

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

14
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

15
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
principals 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
16
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-specifi
  c 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 )

17
GAA_check_authorization

• gaa_check_authorization (
• minor_status, // OUT, mechanism-specific
  status code
• sec_context, // INOUT, 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 )

18
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

19
GAA Error Code

• GAA_AUTHORIZED
• GAA_NOT_AUTHORIZED
• GAA_ADDITIONAL_CHECKS_REQUIRED

20
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

21
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

22
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

23
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,
• applicationChecksum ORapplicationendorser
  (valid certificate required)
• For Dynamic separation of duties,
• Privilegerestricted only one group at a time

24
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-equalconfidentiality-label
• (subject must have equal clearance as to the
  conf-label)

25
(No Transcript)