Download slides

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: 09-15-05
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
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.