Role-Based Access Control and the Access Control Matrix

G. SaundersBasser Department of Computer Science, University of Sydney, Australia

gsaunder@cs.usyd.edu.au

M. Hitchens and V. VaradharajanSchool of Computing & Information Technology, University of Western

Sydney (Nepean), Australia{m.hitchens,v.varadharajan}@uws.edu.au

Abstract

The Access Matrix is a useful model for under-standing the behaviour and properties of accesscontrol systems. While the matrix is rarely im-plemented, access control in real systems is usu-ally based on access control mechanisms, such asaccess control lists or capabilities, that have clearrelationships with the matrix model. In recenttimes a great deal of interest has been shownin Role Based Access Control (RBAC) mod-els. However, the relationship between RBACmodels and the Access Matrix is not clear. Inthis paper we present a model of RBAC basedon the Access Matrix which makes the relation-ships between the two explicit. In the process ofconstructing this model, some fundamental sim-ilarities between certain capability models andRBAC are revealed.

1 Introduction

Computer systems contain large amounts of in-formation. Much of this information is of a sen-sitive nature. For such information it is neces-

sary to be able to define what entities have ac-cess to the information and in what ways theycan access the information. These functions arevariously known as access control or authorisa-tion. The basic model of access control is theAccess Control Matrix (or ACM) [9, 6]. The ac-cess control matrix specifies individual relation-ships between entities wishing access (subjects)and the system resources they wish to access (ob-jects). For each subject-object pair the allow-able access appears in the corresponding entryin the (two-dimensional) matrix. Current accesscontrol mechanisms do not implement the ac-cess control matrix directly, due to well knownefficiency problems [13]. However, most accesscontrol mechanisms in current use are based onmodels, such as access control lists or capabili-ties [3, 4], which have a direct relationship withthe access control matrix.

Recently there has been an increasing interestin other models of access control. One of themore prominent of these has been Role BasedAccess Control (or RBAC) [5, 11, 12]. The in-terest in these alternative approaches to accesscontrol has, at least in part, arisen due to the

1

limited expressive power of the common accesscontrol models. The policies of real world or-ganisations are often of a sophisticated natureand cannot be readily expressed within the sim-ple framework of the access control matrix or itsimmediate derivatives. RBAC, amongst otherproposals [7], shows promise in being able to ex-press real-world policies. The basic elements ofan RBAC system are

1. Users

2. Roles

3. Permissions

Permissions specify the access allowed to objectsand are grouped together in roles, which can bethought of as job descriptions within an organ-isational structure. Users are assigned to roles.This approach has a number of immediate bene-fits. Roles can be given permissions which matchthe organisational policy for the equivalent job.Users can be switched easily between roles, auto-matically changing the permissions available tothem. This is much easier than traditional ac-cess control systems, where the individual per-missions for that user would each have to be up-dated to reflect the abilities of the new position.

As might be expected, the advantages ofRBAC do not come without cost. The ACM is arelatively simple concept and it, and its closelyrelated derivatives (access control lists and ca-pabilities) have been extensively studied. Evenhere though, the differences between access con-trol lists and capabilities have made it difficultto compare systems based on these models inany formal way. In a previous paper [14] we pre-sented a formalism, based on that of Harrison,Ruzzo and Ullman [6] which encompasses bothaccess control lists and capabilities, making iteasier to compare such systems.

In this paper we extend that formalism to en-compass Role Based Access Control. In the pro-cess it becomes clear that role based access con-trol has significant fundamental similarities tocapability based access control.

We begin in the following section with a basicmodel from which the other models are derived.This basic model is revision and simplificationof a model we presented in an earlier work [14]which in turn was based on the matrix model ofHarrison et al. [6].

Section 3 extends the basic model to forma matrix model and suggests some extensionsthat reduce the space requirements of the model.From the resulting matrix model, an Access Con-trol List (ACL) model and a basic capabilitymodel are derived in Sections 4 and 5. In Sec-tion 6 a more complex capability model is de-rived which has some fundamental properties ofRBAC models, and in Section 7 we derive anRBAC model with notable similarities to thiscapability model. Section 8 presents some exam-ples which show these similarities more clearly.Section 9 completes the paper with some con-cluding remarks and areas for further research.

2 The Base Model

We begin with a basic model which is expandedin later sections to describe the various accesscontrol models. The model presented here is arevision and simplification of one we presentedin an earlier work [14], which in turn was basedon the access matrix model of Harrison et al. [6].

We shall base our Access Control Models ona series of definitions, each of which declares theexistence of one of three things:

1. A set

2. A container (list, queue, vector, matrix etc.)the contents of which are either

• Elements of a set defined earlier; or

• A set or container (recursively.)

3. A mapping between sets defined earlier.

Each of the models in this formulation are ex-tensions of the following six definitions, some ofwhich may be augmented or redefined dependingon the model in question.

Definition 2.1 Rts the set of Rights (e.g. read,write, execute)

Definition 2.2 Obj the set of Objects (e.g.files)

Definition 2.3 Sbj the set of Subjects (e.g.users, processes)

Definition 2.4 C the set of commands

Definition 2.5 B the set {grant , deny}

Definition 2.6 f a function from Sbj × Obj ×Rts to B

Each element of C is a command of the form:

command α(X1, . . . , Xi)if cnd1 and

. . .cndj

thenop1 . . . opk

end

The commands provide the only means of manip-ulating the elements of the access control systemin the same way that the methods of an object

enter x into Y delete x from Ycreate object Xo destroy object Xo

create subject Xs destroy subject Xs

Table 1: The primitive operations available tothe commands in C

oriented class provide the only means for manip-ulating the private variables of that class. Thecontents of C are determined by the model un-der consideration, and each model will typicallyprovide commands for creating and destroyingobjects and subjects, and for conferring and re-voking access privileges between subjects.

The symbol α is the name of the command.The arguments, X1 . . . Xi, may be elements ofany set declared earlier. Within the commands,each cnd j is a condition using either the functionf or the operator ‘in’ which is used to test mem-bership in a set or container. Each opk is one ofthe primitive operations in Table 1. The enterand delete operations are defined more gener-ally than in the model of Harrison et al. Theyallow an element x to be entered or removed froma set or container Y . We assume that the otheroperations have intuitive meanings.

The function f is used to determine whether agiven subject has a given right for a given object.The exact definition of this function depends onthe model in question.

3 The Access Control MatrixModel

To model the Access Control Matrix [6] we be-gin with Definitions 2.1–2.6 from the previoussection, and extend them with

Definition 3.1 M a matrix, indexed by Objand Sbj, each element of which is a subset ofRts.

The contents of C from Definition 2.4 are shownin Table 2. Commands for the creation and de-struction of subjects are similar to those for ob-jects and are omitted here and in the later mod-els. The function f from 2.6 takes the form:

f(s, o, rt) =

{grant if rt ∈ M [s, o]deny otherwise

So much for the Access Control Matrix modelthen. As is well known, the space requirementsof the matrix prohibit the actual use of thismodel in a computer system. There are, how-ever, methods for reducing the space required.For example, we can replace Definition 3.1 with:

Definition 3.2 (replaces 3.1) M a set oftriplets (s, o, rts) where s ∈ Sbj, o ∈ Obj andrts ⊆ Rts.

and then remove those triplets where rts = ∅to save space, based on the assumption that themajority of entries in the matrix are, in fact,empty [13]. This would require modifications tothe commands in C, for example in the CREATEcommand we add:

enter (sbj , obj ,{own}) into M

in place of the existing enter operation. How-ever, we can do even better than this. Supposewe group subjects together, with:

Definition 3.3 G a set of groups, where eachgroup is a subset of Sbj.

command CREATE (sbj , obj )create object objenter own into M [sbj , obj ]

end

command DESTROY (sbj , obj )if own in M [sbj , obj ] then

destroy object objend

command CONFERr (sbj , sbj2 , obj )if own in M [sbj , obj ] thenenter r into M [sbj2 , obj ]

end

command REMOVEr (sbj , sbj2 , obj )if own in M [sbj , obj ] thendelete r from M [sbj2 , obj ]

end

command CHOWN (sbj ,new , obj )if own in M [sbj , obj ] then

delete own from M [sbj , obj ]enter own into M [new , obj ]

end

Table 2: The set C of commands for the accesscontrol matrix model.

and modify the commands in C so that a groupmay be given in place of a subject in the param-eter list.1 Then we replace Definition 3.2 with

Definition 3.4 (replaces 3.2) M a set oftriplets (x, o, rts) where x ∈ Sbj ∪G.

1If groups are not to be owners of objects, they mustnot be allowed to replace subjects in the CREATE andCHOWN commands.

By using groups in this way, we reduce thenumber of triplets in M , resulting in a modelthat does not have the prohibitive space require-ments of the access control matrix. Unfortu-nately it is likely to have prohibitive computa-tional time requirements (which is to say that theexecution of f will take a considerable amountof time). We turn now to methods for reducingthese time requirements.

4 The Access Control ListModel

In order to reduce the computational time re-quirements of the revised matrix model, we mustreduce the number of entries in M that are con-sidered during the execution of f . We can dothis by partitioning M into small discrete por-tions based on either subject or object. In thissection we consider partitioning M by object.

We begin again with Definitions 2.1–2.6, andextend them with:

Definition 4.1 Cols a vector indexed by Obj.Each entry in Cols is a vector indexed by theelements of Sbj. The entries of each vector aresubsets of Rts.

This is just the matrix split into column vec-tors. We can remove the empty elements fromthese column vectors to obtain:

Definition 4.2 (replaces 4.1) Cols a vectorindexed by Obj. Each element of Cols is a set of(s, rts) tuples where s ∈ Sbj and rts ∈ Rts.

To further reduce space requirements we canuse groups from Definition 3.3 above to obtain:

command CREATE (sbj , obj )create object objenter (sbj , own) into Cols[obj ]

end

command DESTROY (sbj , obj )if f(sbj , obj , own) then

destroy object objend

command CONFERr (sbj , sbj2 , obj )if f(sbj , obj , own) then

enter sbj2 , {r} into Cols[obj ]end

command REMOVEr (sbj , sbj2 , obj )if f(sbj , obj , own) then

delete sbj2 , {r} from Cols[obj ]end

command CHOWN (sbj ,new , obj )if f(sbj , obj , own) thendelete (sbj , {own}) from Cols[obj ]enter (new , {own}) into Cols[obj ]

end

Table 3: The set C of commands for the accesscontrol list model.

Definition 4.3 (replaces 4.2) Cols a vectorindexed by Obj. Each element of Cols is a set of(x, rts) tuples where x ∈ Sbj ∪G and rts ∈ Rts.

The set of commands, C, is shown in Table 3and the function f takes the form:

f(s, o, rt) =

grant ifrt ∈ {y|(x, rts) ∈

Cols[o] ∧ (s = x ∈ Sbj∨s ∈ x ∈ G) ∧ y ∈ rts}

deny otherwise

and thus we arrive at the basic Access Con-trol List (ACL) model used in systems such asUnix. However, it is possible to reduce the stor-age requirements even further by storing only theunique (x, rts) tuples. This step is rarely takenin ACL systems, however a similar approach isused to reduce storage requirements in capabilitysystems. Appropriate definitions for this are:

Definition 4.4 SR a set of (s, rts) tuplesformed by taking the union of all sets in Cols.

Definition 4.5 SRA a many-to-many mappingfrom SR to Obj.

Access Control Lists view the Access Matrix ina column-wise fashion. An alternative approachwould be to view them in a row-wise manner.This is the approach taken by capabilities.

5 A Capability Model

Capability systems (e.g. [3, 4]) partition M bysubject rather than object. We can do this ina similar manner to the one used above for theACL model. We begin with definitions 2.1–2.6and extend them with:

Definition 5.1 Rows a vector indexed by the el-ements of Sbj. Each entry of Rows is a vectorindexed by the elements of Obj. The entries ofeach vector are subsets of Rts.

and, as with the list model described above, weremove empty elements to obtain:

Definition 5.2 (replaces 5.1) Rows a vectorindexed by Sbj. Each element of Rows is a setof (o, rts) tuples where o ∈ Obj and rts ⊆ Rts.

command CREATE (sbj , obj )create object objenter (obj , {Rts}) into ORenter ((obj , {Rts}), sbj ) into ORAend

command DESTROY (sbj , obj )if f(sbj , obj , destroy) thendestroy object obj

end

command CONFERr(sbj , sbj2 , obj )if f(sbj , obj , confer) thenenter (obj , {r}) into ORenter ((obj , {r}), sbj2 ) into ORA

end

command REMOVE r(sbj , sbj2 , obj )if f(sbj , obj , remove) thendelete ((obj , {r}), sbj2 ) from ORA

end

Table 4: The set C of commands for the capa-bility model.

Storing only the unique (o, rts) tuples, is com-mon in capability systems as it reduces storagerequirements. This approach can be modelledby means of a central capability table, using:

Definition 5.3 OR a set of (o, rts) tuples,formed by taking the union of all the sets inRows.

Definition 5.4 ORA a many-to-many mappingfrom OR to Sbj.

The set of commands, C is defined in Table 4and the function f takes the form:

f(s, o, rt) =

grant ifrt ∈ {x|(o, rts ∈ OR∧

((o, rts), s) ∈ ORA∧x ∈ rts}

deny otherwise

This gives us a model that behaves in a sim-ilar manner to early capability systems whichutilised a central capability table. Unfortu-nately, central capability systems have sufferedfrom performance problems [8], and more re-cent capability systems take a different approachwhich is described in the following section.

The groups concept can be applied in multipleways with capabilities. One interesting way is tohave groups of objects instead of subjects. Anobject in one of the commands in Table 4 couldbe replaced by a group of objects.

6 Capability Container Sys-tems

Some capability systems, (e.g. [2] and [1]), allowcapabilities to be stored within objects. Whena subject wishes to access an object, they lo-cate a capability within one of their objects andpresent it to the system. Beginning again withDefinitions 2.1–2.6 and Definition 5.3, this canbe modelled in the following way:

Definition 6.1 CapO a set of objects that maycontain capabilities, and such that CapO ⊆ O.

Definition 6.2 CA a many-to-many mappingfrom OR to CapO.

Instead of storing capabilities in a centralrepository (OR), they are stored within objects.The CA mapping simply tells us which capabil-ities are contained in a particular CapO .

This scheme raises a number of interesting is-sues. Firstly, what capabilities does a subjectpossess on creation? One possibility would be tocreate a mapping from some characteristic of thenew subject, its owner for example, to a set ofcapabilities which the subject will possess on cre-ation. Another solution would have the subjectinherit some or all of the capabilities of its par-ent. These solutions are not mutually exclusive,and the second has the advantage of being ableto support the principle of least privilege by dy-namically restricting the capabilities that a childsubject inherits, or perhaps by temporarily de-activating capabilities under certain conditions(for example, the password capability system ofAnderson et al. [1] has facilities for doing this).To model this we introduce:

Definition 6.3 proclist a many-to-many map-ping from Sbj to OR.

which tells us which of the capabilities held in asubject can be used at the present time.2

Another issue raised by this scheme is thatby possessing a capability for a capability con-taining object a subject may, depending on therights in the capability, be able to acquire anduse the capabilities in that object. We desig-nate the set of capability containing objects fromwhich a subject can acquire capabilities as theactive capability containing objects.

Definition 6.4 active a many-to-many map-ping from Sbj to CapO giving the CapOs whichare reachable from a given subject. A CapOcalled x is reachable by a subject s if x = s, orif a capability for x is an element of proclist(s),

2proclist is implementation dependent, so the mecha-nism by which it determines its results is not discussedhere.

command CREATE (sbj , obj )create object objenter (obj , {Rts}) into sbj

end

command DESTROY (sbj , obj )if f(sbj , obj , destroy) thendestroy object obj

end

command CONFERr(sbj , capo, obj )if f(sbj , obj , confer) thenenter (obj , {r}) into capo

end

command REMOVE r(sbj , sbj2 , obj )if f(sbj , obj , remove) thendelete (obj , {r}) from capo

end

Table 5: The set C of commands for the capa-bility container model.

or if a capability for x is an element of CA(y)(where y ∈ CapO) and y is reachable.

A process wishing to access an object wouldsimply present a capability for the object fromamong the capabilities available in any of theobjects to which it has a capability, or can getone. The function f therefore takes the form

f(s, o, rt) =

grant if (o, rts) ∈ proclist(s)∨

(o, rts) ∈ ∪c∈active(s){x|x ∈ CA(c)} ∧ rt ∈ rts

deny otherwise

and the set C of commands is shown in Table 5.

7 Role Based Access ControlModels

We are now ready to discuss Role Based AccessControl (RBAC) models.

Sandhu et al. [11] define four reference modelsfor Role Based Access Control. RBAC0 defines abasic RBAC system. RBAC1 augments RBAC0

with role hierarchies. RBAC2 adds constraintsto RBAC0 and RBAC3 combines RBAC1 andRBAC2. In this paper we focus on RBAC1,which has the following components [11]

• U,R, P and S (users, roles, permissions, andsessions respectively);

• PA ⊆ P ×R, a many-to-many permission torole assignment relation;

• UA ⊆ U × R, a many-to-many user to roleassignment relation;

• user : S → U , a function mapping each ses-sion si to the single user user(si) (constantfor the session’s lifetime);

• RH ⊆ R × R is a partial order on R calledthe role hierarchy or role dominance rela-tion, also written as ≥; and

• roles : S → 2R, a function mapping eachsession si to a set of roles roles(si) ⊆{r|(∃r′ ≥ r)[(user(si), r′) ∈ UA]} (whichcan change with time) and session si

has the permissions ∪r∈roles(si){p|(∃r′′ ≥r)[(p, r′′) ∈ PA]}.

It may come as a surprise to realize that thereare fundamental similarities between the Con-tainer Based Capability model presented earlier,and Role Based Access Control Models. In fact,

the process of deriving a Role Based Access Con-trol Model from the model presented in the pre-vious section is largely one of renaming.

We extend our previous definitions with:

Definition 7.1 (replaces 5.3) P the set ofPermissions, such that P = OR.

The subjects in a Role Based Access Controlsystem are neither users, nor processes, but anew entity called a session. When a user logsin, they create a new session which is active in asubset of their roles (see below). This is analo-gous to a user logging in and creating a processwith a subset of their capabilities. The functionf must be redefined in light of this:

Definition 7.2 S the set of Sessions.

Definition 7.3 (replaces 2.6) f a functionfrom S ×Obj× Rts to B

In RBAC systems, roles relate users to per-missions. This is analogous to giving a user acapability for a capability containing object.

Definition 7.4 R a set of Roles.

Perhaps the most important difference be-tween container based capability models andRBAC models is that roles are not objects asCapOs are. Therefore, it is not possible to ma-nipulate roles in the same way that normal sys-tem objects can be manipulated.

Also, a permission is not required to access aRole. Instead, role membership is determinedindependently of any permissions held by a user(indeed, the permissions held by a user are de-termined by role membership.)

Lastly, roles are not, strictly speaking, setsof permissions (though they can be usefully

command CREATE (role, obj )create object objenter (obj , {Rts}) into Penter ((obj , {Rts}), role) into PAend

command DESTROY (role, obj )if f(role, obj , destroy) thendestroy object obj

end

command CONFERr (role1 , obj , role2 )if f(role1 , obj , confer) thenenter ((obj , {r}), role2 ) into PA

end

command REMOVEr (role1 , obj , role2 )if f(role1 , obj , remove) thendelete ((obj , {r}), role2 ) from PA

end

Table 6: The set C of commands for the rolebased model.

thought of as such). So we require a mecha-nism to tell us which permissions are assigned toa role, just as we required a mechanism to mapcapabilities to the objects which contained them.

Definition 7.5 (replaces 6.2) PA a many-to-many mapping from P to R.

In the container based capability models, thesubjects are themselves capability containersand therefore behave in a similar manner toroles. In RBAC they are restricted to merelyinheriting permissions from roles, they are notable to contain permissions that are not inher-ited from roles. Furthermore, it is not possible to

obtain permissions from a Subject by possessinga permission for that subject.

We require a mechanism to tell us whichroles are being used by a particular session.This mechanism performs a similar function toproclist from Definition 6.3, in that it allows fora subset of the available roles to be made active.

Definition 7.6 roles a many-to-many mappingfrom S to R.

Some RBAC models allow roles to be partiallyordered in a Role Hierarchy. This is analogousto having a capability containing object whichcontains capabilities for other capability contain-ing objects. The active mapping from Definition6.4 provides an almost identical function in con-tainer based capability models. In RBAC modelsthe role hierarchy is defined by

Definition 7.7 RH A partial order on the setR of roles.

The commands of the set C are defined in Ta-ble 6 and the function f from Definition 7.3 takesthe form

f(s, o, rt) =

grant if (o, rts) ∈ ∪rl∈roles(s)

{p|p ∈ PA[rl]}∧rt ∈ rts

deny otherwise

We now have a basic RBAC model derivedfrom the container based capability model of theprevious section. The following sections presentexamples to illustrate the similarities betweenRBAC and container based capability models.

8 Some Examples

In this section we illustrate the similarities be-tween Role Based models and capability con-

tainer models with examples taken from Sandhuet al.[11].

8.1 Chief Security Officer Example

Consider the role hierarchy found in Figure 1(a)in which a Chief Security Officer (CSO)role inherits from three junior Security Of-ficer (SO) roles. In this example, the setR of roles is simply {CSO,SO1, SO2, SO3},and the partial order set RH contains{(SO1, CSO), (SO2, CSO), (SO3, CSO)}.

Figure 1(b) is an example access control ma-trix describing the rights each of the security offi-cer roles has for objects O1, O2 and O3. In a RoleBased system, this matrix is represented by theset P of permissions which contains

O1, {read}︸ ︷︷ ︸p1

O2, {read ,write}︸ ︷︷ ︸p2

O2, {read , execute}︸ ︷︷ ︸p3

O3, {read ,write}︸ ︷︷ ︸p4

and the permission assignment set, PA, con-

tains {(p1,SO1 ), (p1,SO2 ), (p2,CSO),

(p3,SO2 ), (p4,SO3 )

}This means that any user active in the CSO roleis able to use permission p2 and also any of theother permissions by virtue of the inheritancerelationships.

Figure 2 illustrates the same scenario interms of the capability container model. Theset of capability containing objects, CapO ,would be {CSO ,SO1 ,SO2 ,SO3}. The capabil-ities contained within the CSO object include{(SO1 , acq), (SO2 , acq), (SO3 , acq)} where acqrepresents the set of rights which enable the ac-quisition and use of capabilities from the desti-nation object.

CSO

CSO

SO1SO1 SO2SO2 SO3SO3

O1 O2 O3

CSO read, write

SO1 read

SO2 read read, execute

SO3 read, write

(a) Role Hierarchy (b) Access Matrix

Figure 1: The chief security officer example

SO1, {acq} SO2, {acq} SO3, {acq} O2, {r, w}

CSOCSO

O1, {r}

SO1SO1

O1, {r} O2, {r, x}

SO2SO2

O3, {r, w}

SO2SO2

O1O1O2O2

O3O3

Figure 2: The example using the capability container model.

In addition to the capabilities mentionedabove, the set of capabilities OR contains thepermissions of set P . Furthermore, the SO1 ob-ject contains the capability p1, the SO2 objectcontains the capabilities p1 and p3, the SO3 ob-ject contains p4 and lastly, the CSO object con-tains p2. Since CSO also contains capabilities forSO1 ,SO2 and SO3 , any user who holds a capa-bility for CSO is able to retrieve and use capa-bilities from SO1 ,SO2 and SO3 in an analogousway to role inheritance.

8.2 Project Supervisor Example

In this section we present a more complex ex-ample, again taken from Sandhu et al. [11].Figure 3(a) is a role hierarchy in which a projectsupervisor role (S) inherits two task roles (T1and T2) which, in turn, inherit a general projectrole (P). In addition, the supervisor role inheritsa subproject supervisor role (S3), which inheritsanother two task roles (T3 and T4), which in-herit from a subproject role (P3), which, finally,inherits the project role.

The set R of roles in this example is{S ,S3 ,T1 ,T2 ,T3 ,T4 ,P3 ,P}, and the role hi-erarchy set RH is

(S3 ,S ), (T1 ,S ), (T2 ,S ), (T3 ,S3 ),(T4 ,S3 ), (P ,T1 ), (P ,T2 ), (P3 ,T3 ),

(P3 ,T4 ), (P ,P3 )

The set P of permissions is

O1, {r}︸ ︷︷ ︸p1

O1, {r, w, x}︸ ︷︷ ︸p2

O2, {w, x}︸ ︷︷ ︸p3

O2, {r}︸ ︷︷ ︸p4

O3, {r, w}︸ ︷︷ ︸p5

O4, {x}︸ ︷︷ ︸p6

O4, {w, x}︸ ︷︷ ︸p7

O4, {r}︸ ︷︷ ︸p8

Lastly, the permission assignment relation,PA, contains{

(p1 ,T1 ), (p2 ,T2 ), (p3 ,T2 ), (p4 ,P),(p5 ,T3 ), (p6 ,T3 ), (p7 ,T4 ), (p8 ,P3 )

}

Figure 4 illustrates the capability con-tainer version of this example. Thereare eight capability containing objects,{S ,S3 ,T1 ,T2 ,T3 ,T4 ,P3 and P}. Object Scontains the capabilities for T1 ,T2 and S3 .Object S3 contains capabilities for T3 and T4 .Objects T1 ,T2 and P3 each contain capabil-ities for P . Finally, objects T3 and T4 eachcontain a capability for P3 . Each of thesecapabilities has the acq permission, whichpermits the acquisition and use of capabilitiesfrom the destination object.

In addition to the capabilities described above,the set of capabilities OR also contains the per-missions from set P . Object T1 contains the p1

capability. Object T2 contains the p2 and p3 ca-pabilities. Object T3 contains p5 and p6. T4contains p7. P3 contains p8, and lastly, objectP contains the capability p4. This means thatanyone in possession of a capability for objectS can acquire and use any of the capabilitiesdescribed above in a manner analogous to roleinheritance.

9 Conclusion

In this paper we have presented a formal modelof Role Based Access Control which is derivedform the Access Control Matrix. This model isderived from the initial work of Harrison, Ruzzoand Ullman on access control models. Such amodel places RBAC in relation to the traditionalaccess control models and enables comparisonsto be made between systems based on the various

S

S

S3

S3

T1

T1

T2

T2

T3

T3

T4

T4

P3P3

P P

O1 O2 O3 O4

S

S3

T1 r

T2 r, w, x w, x

T3 r, w x

T4 w, x

P3 r

P r

(a) Role Hierarchy (b) Access Matrix

Figure 3: The project role hierarchy

models. In the process we have demonstratedfundamental similarities between RBAC and ca-pabilities. That RBAC should be related to oneor the other of the basic derivatives of the ACMshould come as no surprise. The ACM is thefundamental expression of discretionary accesscontrol and access control lists and capabilitiesrepresent the two intuitive methods of viewing it.Therefore it could reasonably be expected thatRBAC would show some relationship to one orthe other. However, the high degree of similarityfound may not have been so expected.

Understanding the relationship between capa-bilities and RBAC and, more distantly, RBACand the ACM, opens the possibility of applyingresults known for those models to RBAC (andvice-versa). It should also simplify comparisons,such as in terms of safety analysis, between sys-tems based on the various models.

Two broad areas of future work offer them-selves. First is the examination of the implica-

tions of placement of RBAC in a taxonomy of ac-cess control models. Does its similarity to capa-bilities indicate that implementations of RBACbased on capabilities have promise? Can knownproperties of capability systems be applied toRBAC systems?

The second area further extending our formal-ism into other access control models, such as theChinese Wall and other lattice based models [10].

Acknowledgements

We extend our gratitude to the anonymous re-viewers whose suggestions have considerably im-proved this paper.

References

[1] M. Anderson, R. D. Pose, and C. S. Wallace.A password-capability system. The Com-

T1,{acq} T2,{acq} S3,{acq}

SS

T3,{acq} T4,{acq}

S3S3

P,{acq} p1

T1T1

P,{acq} p2 p3

T2T2

P3,{acq} p5 p6

T3T3

P3,{acq} p7

T4T4

P,{acq} p8

P3P3

p4

PP

O1O1O2O2

O3O3O4O4

Figure 4: The example using the capability container model.

puter Journal, 29(1):1–8, February 1986.

[2] A. Dearle, R. di Bona, J. Farrow,F. Henskens, D. Hulse, A. Lindstrom,S. Norris, J. Rosenberg, and R. Vaughan.Protection in the grasshopper operatingsystem. In Proceedings of the 6th Interna-tional Workshop on Persistent Object Sys-

tems, pages 54–72, September 1994.

[3] J. B. Dennis and E. C. Van Horn. Program-ming semantics for multiprogrammed com-putations. Communications of the ACM,9(3):143–155, March 1966.

[4] R. S. Fabry. Capability-based addressing.Communications of the ACM, 17(7):403–

412, July 1974.

[5] D. Ferraiolo and R. Kuhn. Role-based ac-cess controls. In 15th NIST-NCSC NationalComputer Security Conference, pages 554–563. October 1992.

[6] M. A. Harrison, W. L. Ruzzo, and J. D.Ullman. Protection in operating systems.Communications of the ACM, 19(8):461–471, August 1976.

[7] S. Jajodia, P. Samarati, V. S. Subrahma-nian, and E. Bertino. A unified frameworkfor enforcing multiple access control poli-cies. In Proceedings ACM SIGMOD In-ternational Conference on Management ofData, pages 474–485, 1997.

[8] P. A. Karger. Improving security and per-formance for capability systems. TechnicalReport 149, University of Cambridge Com-puter Laboratory, Cambridge, England, Oc-tober 1988. Dissertation submitted for thedegree of Doctor of Philosophy.

[9] B. W. Lampson. Protection. Operating Sys-tems Review, 8(1):18–24, January 1974.

[10] R. S. Sandhu. Lattice-based access con-trol models. IEEE Computer, 26(11):9–19,November 1993.

[11] R. S. Sandhu, E. J. Coyne, H. L. Feinstein,and C. E. Youman. Role-based access con-trol models. IEEE Computer, 29(2):38–47,February 1996.

[12] R. S. Sandhu, D. Ferraiolo, and R. Kuhn.The nist model for role-based access control:Towards a unified standard. In Proceedingsof the Fifth ACM Workshop on Role-BasedAccess Control, pages 47–63, 2000.

[13] R. S. Sandhu and P. Samarati. Access con-trol: Principles and practice. IEEE Com-munications Magazine, 32(9):40–48, 1994.

[14] G. Saunders, M. Hitchens, and V. Varad-harajan. An analysis of access control mod-els. In Proceedings of the Fourth Aus-tralasian Conference on Information Secu-rity and Privacy, 1999.