Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies (2000) Author: Sylvia Osborn, Ravi Sandhu,Qamar Munawer Presenter: Siqing Du Date:

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.

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

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.

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 X R, a many-to-many permission to role assignment relation  APA  AP X AR, a many-to-many permission to administrative role assignment relation  UA  U X R, a many-to-many user to role assignment relation  AUA  U X AR, a many-to-many user to administrative role assignment relation  RH  R X R, a partially ordered role hierarchy  ARH  AR X AR, partially ordered administrative role hierarchy

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)

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

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

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)

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.

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.

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.

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.

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.

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  …

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.