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

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.

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

Uploaded by

Copyright:

Available Formats

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

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Configuring Role-Based Access Control to

Enforce Mandatory and Discretionary

Author: Sylvia Osborn, Ravi Sandhu ,Qamar Munawer

P = { (o,r),(o,w)| o is an object in the system}

You might also like