Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies (2000)

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

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