Author: Sylvia Osborn, Ravi Sandhu ,Qamar Munawer Presenter: Siqing Du Date: 09-15-05

1. Configuring Role-Based Access Control toEnforce Mandatory and DiscretionaryAccess Control Policies(2000) Author: Sylvia Osborn, Ravi Sandhu ,Qamar Munawer Presenter: Siqing Du Date: 09-15-05

2. Introduction • Role-based access control (RBAC) as a alternative to traditional discretionary and mandatory access controls. • Users can be easily reassigned from one role to another. • Roles can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. • Greatly simplifies management of permissions. • The ability to modify policy to meet the changing needs of an organization is an important benefit of RBAC.

3. Traditional Access Control Models • Mandatory access control(MAC) Or call lattice-based access control (LBAC) • one-directional information flow • the notion of a role and the level of a login session is similar • role hierarchies and constraints are critical • Discretionary access control (DAC) • the owner of an object has discretionary authority over who else can access that object. • Administrative roles are crucial and adequate

4. RBAC Models

5. RBAC Models • The model is based on three sets of entities called users (U), roles (R), and permissions (P). • A user is a human being or an autonomous agent. • A role is a job function or job title within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role. • A permission is an approval of a particular mode of access to one or more objects in the system. • Role hierarchy RH, written as ≥ • RBAC96 distinguishes roles and permissions from administrative roles and permissions.

6. Some Definition • U, a set of users • R and AR, regular roles and administrative roles • P and AP, regular permissions and administrative permissions • S, a set of sessions • PA P XR , a many-to-many permission to role assignment relation • APA AP XAR, a many-to-many permission to administrative role assignment relation • UA U XR , a many-to-many user to role assignment relation • AUA U XAR, a many-to-many user to administrative role assignment relation • RH R XR , a partially ordered role hierarchy • ARH AR XAR, partially ordered administrative role hierarchy

7. LBAC (MAC) Models • The mandatory access control policy is expressed in terms of security labels attached to subjects and objects. • A label on an object is called a security classification • A label on a user is called a security clearance. • Read-down (s) ≥ (o) • Write-up (s) ≤ (o) • Write-equal (s) = (o)

8. Configuring RBAC for LBAC Read-down Write-up Read-down Write-equal

9. The General Construction • Construction1 (Liberal *-Property) (write-up) R = {L1R. . . LnR, L1W. . . LnW} RH which consists of two disjoint role hierarchies. The first role hierarchy consists of the “read“ roles {L1R. . . LnR} and has the same partial order as ≥LBAC ; the second partial consists of the “write” roles {L1W. . . LnW} and has a partial order which is the inverse of ≥LBAC . P = { (o,r),(o,w)| o is an object in the system} Constraint on UA: Each user is assigned to exactly two roles xR and LW where x is the label assigned to the user and LW is the write role corresponding to the lowermost security level according to ≥ LBAC Constraint on sessions: Each session has exactly two roles yR and yW Constraints on PA: (o,r) is assigned to xR iff (o,w) is assigned to xW (o,r) is assigned to exactly one role xR such that x is the label of o

10. Some other constructions • Construction 2. (Strict *-Property) Identical to Construction 1 except RH has a partial order among the read roles identical to the LBAC partial order, and no relationships among the write roles. • Construction 3. (Liberal *-Property with Trusted Range) • Construction 4. (Liberal *-Property with Independent Write Range) • Construction 5. (Strict *-Property with Designated Write)

11. DAC Models DAC is that the owner of an object, who is usually its creator, has discretionary authority over who else can access that object. • DAC can be simulated in RBAC • The DAC policies: • The creator of an object becomes its owner. • There is only one owner of an object. • Destruction of an object can only be done by its owner.

12. Variations of DAC • Strict DAC requires that the owner is the only one who has discretionary authority to grant access to an object and that ownership cannot be transferred. • Liberal DAC allows the owner to delegate discretionary authority for granting access to an object to other users. Variations of liberal DAC • One Level Grant: The owner can delegate grant authority to other users but they cannot further delegate this power. • Two Level Grant: In addition to a one-level grant the owner can allow some users to further delegate grant authority to other users. • Multilevel Grant: • DAC with Change of Ownership: This variation allows a user to transfer ownership of an object to another user.

13. Configuring RBAC for DAC • The basic idea is to simulate the owner-centric policies of DAC using roles that are associated with each object. • Create an Object. For every object O that is created, three administrative roles and one regular role are also created.

14. Eight Permissions • creating the following eight permissions along with creation of each object O. • — canRead_O: It is assigned to the role READ_O. • — destroyObject_O: It is assigned to the role OWN_O. • — addReadUser_O, deleteReadUser_O: They are assigned to the role PARENT_O. • — addParent_O, deleteParent_O:They are assigned to the role PARENTwithGRANT_O. • — addParentWithGrant_O, deleteParentWithGrant_O: They are assigned to the role OWN_O.

15. Strict DAC • Only the owner can grant/revoke read access to/from other users. • The creator is the owner of the object. • Membership of the three administrative roles cannot change. • This policy can be enforced by imposing a cardinality constraint of 1 on OWN_O and of 0 on PARENT_O and PARENTwithGRANT_O. • This policy could be simulated using just two roles OWN_O and READ_O, and giving the addReadUser_O and deleteReadUser_O permissions directly to OWN_O at creation of O.

16. Liberal DAC • One-Level Grant. The one-level grant DAC policy can be simulated by removing the cardinality constraint of strict DAC on membership in PARENT_O. The owner can assign users to the PARENT_O role who in turn can assign users to the READ_O role. But the cardinality constraint of 0 on PARENTwithGRANT_O remains. • Two-Level Grant. • Multilevel Grant. • DAC with Change of Ownership • …

17. Conclusion • This paper has shown common forms of LBAC and DAC models can be simulated and enforced in RBAC96 with systematic constructions. • Users and permissions are essential to express any access control model. • The Role Hierarchy is important in the LBAC simulation. • The Administrative Role Hierarchy is essential in the enforcement of DAC policies. • Constraints play a role in all of the constructions. • LBAC simulation assumes a single administrative role, whereas the DAC simulation requires a large number of administrative roles, which are dynamically created and destroyed.