Role Based Access Control on MLS Systems Without Kernel Changes

Role Based Access Control on For example, roles in a bank may include the role

of teller or accountant. Each of these roles has a set of

MLS Systems without Kernel

privileges or transactions that they can p erform, includ-

Changes ing some privileges that are available to b oth roles. Roles

can b e hierarchical. For example, some roles in a hospital

D. Richard Kuhn may b e health care provider, nurse, and do ctor. The do c-

National Institute of Standards and Technology tor role may include all privileges available to the nurse

Gaithersburg, Maryland 20899 role, which in turn includes all the privileges available to

the health care provider role.

Roles have b een used in a variety of forms for com-

Abstract

puter system security for at least 20 years, and several

prop osals for incorp orating roles into existing access con-

Role based access control (RBAC) is attracting increas-

trol mechanisms have b een published [2], [3], [4]. More

ing attention as a security mechanism for b oth commer-

recently, formal defnitions for general-purp ose RBAC no-

cial and many military systems. This pap er shows how

tions have b een prop osed [5], [6], [7].

RBAC can b e implemented using the mechanisms avail-

This pap er shows how RBAC can b e implemented

able on traditional multi-level security systems that im-

using the controls available on traditional lattice-based

plement information fow p olicies. The construction from

multi-level secure systems. This approach presents a

MLS to RBAC systems is signifcant b ecause it shows that

number of advantages:

the enormous investment in MLS systems can b e lever-

aged to pro duce RBAC systems. The metho d requires no • Many frms have sp ent hundreds of millions of dol-

changes to the existing MLS system kernel and allows im- lars building, testing, and maintaining MLS systems.

plementation of hierarchical RBAC entirely through site By implementing RBAC using a single trusted pro-

confguration options. A single trusted pro cess is used to

cess, this investment can b e leveraged to pro duce new

map privileges of RBAC roles to MLS lab els. Access is

systems that have great commercial value without re-

then mediated by the MLS kernel. Where C is the num- quiring a similarly large investment to build entirely

b er of categories and d the depth of the role hierarchy, the new RBAC systems.

number of roles that can b e controlled is approximately

• The assurance pro cess for trusted systems is lengthy

C ;d

and exp ensive. By confning RBAC to a single

C ;2d

trusted pro cess that sits ab ove the MLS kernel,

the assurance pro cess should b e much less exp en-

sive than that required for an entirely new system.

1 Introduction

Since RBAC is implemented through confguration

Role based access control (RBAC) is an alternative to

options, a system can provide RBAC while retaining

traditional discretionary (DAC) and mandatory access

the same high assurance level.

control (MAC) p olicies that is attracting increasing at-

• Op erating RBAC and MLS security simultaneously

tention [1], particularly for commercial applications. The

on a system may b e much easier to analyze for assur-

principle motivation b ehind RBAC is the desire sp ecify

ance purp oses. By using only combinations of cat-

and enforce enterprise-spec ifc security p olicies in a way

egory lab els to implement RBAC, information fow

that maps naturally to an organization's structure. Tra-

can b e protected using the conventional sets of secu-

ditionally, managing security has required mapping an

rity levels and categories.

organization's security p olicy to a relatively low-level set

of controls, typically access control lists.

With RBAC, security is managed at a level that cor-

2 Implementing RBAC on Multi-

resp onds closely to the organization's structure. Each

level Secure Systems

user is assigned one or more roles, and each role is as-

signed one or more pr iv il eg es that are p ermitted to users

RBAC can b e implemented directly on multi-level secure

in that role.

(MLS) systems that supp ort the traditional lattice based

controls. This is signifcant b ecause it means the enor-

mous investment in MLS systems can b e applied to im-

plementing RBAC systems. The metho d describ ed here

C ;d

can handle approximately RBAC privileges,

C;2d

where C is the number of categories supp orted on the

MLS system. and d the depth of the role hierarchy.

2.1 MLS Access Controls categories to RBAC privileges. This approach is used in

the Data General DG/UX B2 Secure System [12]. For

MLS access controls make use of a set of lab els attached

small numbers of privileges, this is an efcient solution.

to sub jects and ob jects. The lab els defne a set of se-

DG/UX supp orts up to 128 separate roles. Users can

curity levels, such as CONFIDENTIAL, SECRET, TOP

simply b e assigned a set of categories that corresp ond to

SECRET, and a set of categ or ies, such as NATO, NO-

the privileges of their roles, then access is handled by the

FORN. Conventional MLS systems implement the mil-

MLS system.

itary security p olicy defned by the Bell and LaPadula

Unfortunately, most MLS systems supp ort a rela-

mo del [8].

tively small number of categories and levels, typically 64

We assume a standard set of features and functions

to 128 of each. Obviously, if the MLS system were testing

for an MLS system, such as those describ ed in [9] or [10].

that l > l ^ c = c , rather than l > l ^ c < c , then

s o o s s o o s

The MLS system is assumed to maintain the following

we could simply use subsets of categories to map to priv-

sets:

ileges, giving a total of 2 mappings. But since we want

L = an ordered set of security clearance levels l ;

to b e able to control access to RBAC privileges simul-

C = a set of category names c.

taneously with MLS access control without changing the

Each sub ject s has a set of category names c authorized

MLS system, we need a metho d that can uniquely rep-

for use by sub ject s, and each ob ject o has a set of cat-

resent a large number of privileges using MLS categories

egory names c asso ciated with the ob ject. Levels and

and levels.

categories defne lab els for sub jects s and ob jects o, des-

One alternative is to establish a mapping b etween

ignated A(s) and A(o) resp ectively. The lab els form a

RBAC privileges and pairs of MLS categories. This ap-

lattice where A(i) > A(j ) if l > l and c 2 c

i j i j

proach would supp ort a total of (n ; n);2 privilege map-

For read and activate access, the mandatory ac-

pings. If 64 categories are available on the MLS system,

cess control rules require the simple security prop erty:

then 2, 016 privileges could b e mapp ed to MLS categories.

A(s) > A(o). For write access, the *-prop erty controls

This is a more reasonable number, but large organiza-

access. The traditional, or lib eral *-prop erty requires

tions may require many more individual privileges to b e

that A(o) > A(s). The strict *-prop erty, designed to

controlled. Also, in some applications only a very small

prevent integrity problems as a result of \write-up", re-

number of categories may b e available. If only 10 cat-

quires A(o) = A(s). A variation on the *-prop erty, the

egories were available, then only 45 privileges could b e

trusted lib eral *-prop erty, intro duced by Bell [11], desig-

controlled in this manner.

nates separate lab els for read and write, A and A re-

r w

A more generalized approach is to use combinations

sp ectively. The simple security rule is applied for A and

of categories. For c categories, the largest number of priv-

the *-prop erty for A .

ileges that can b e distinguished is

c;2

2.2 MLS to RBAC Mapping

With 64 categories, this would b e 1:83 x 10 .

A role can b e thought of as a set of p ermissions on priv-

ileges. RBAC can then b e implemented on an MLS sys-

2.3 Construction of Category Sets

tem by establishing a relationship b etween privilege sets

within the RBAC system and category sets within the

This section describ es a metho d of implementing RBAC

MLS system.

by mapping from roles to categories at system initializa-

To implement RBAC, a trusted interface function is

tion time. Only category sets are used; security levels are

developed to ensure that the assignment of levels and cat-

not needed to control access to RBAC-protected ob jects.

egories to users is controlled according to the RBAC rules.

This makes it p ossible to use RBAC simultaneously with

No mo difcations to the MLS system are necessary. Roles

the information-fow p olicies supp orted on MLS systems.

and their asso ciated privilege sets must b e mapp ed by

the interface function to sets of categories. The trusted

2.3.1 Roles and Privilege Sets

interface op erates according to the rules given in Section

2.1. Each time a user establishes a session, the interface

Let R b e a tree of roles and asso ciated privileges, where

presents the user's role options, then checks to ensure that

the ro ot R represents one or more privileges that are

the user is authorized for the requested role. The trusted

available to all roles in the system. Child no des repre-

interface then sets the sub ject's categories according to a

sent more sp ecialized privilege sets. A child no de R can

mapping function that determines a unique combination

access all privileges asso ciated with role R and any as-

of categories for the role requested. (See Figure 1.)

so ciated with roles R , where R are any ancestor no des

i i

A problem arises in the choice of the mapping func- of R . The privilege sets are assumed to b e disjoint. If

tion. One p ossibility is the one-to-one assignment of MLS roles exist with overlapping privilege sets, then new roles

can b e created with the common privileges and existing with a category. Assign to each privilege set at level l a

roles can inherit from them. For example, if R and R diferent number from L . Then lab el each privilege in

i j 2

have privilege sets P (R ) and P (R ) that overlap, then a privilege set with category i if and only if bit i in the

i j

1. create a new role R with privilege set P (R ) \ binary representation is a 1. For example, the mapping

k i

P (R ) from bits to categories in Table 1 shows how the pro ce-

2. remove privileges in P (R ) \ P (R ) from R and dure works for c = 3 categories. Extracting all sets of

i j i

2 categories from the list gives fc , c g, fc , c g, fc , c g.

2 1 3 1 3 2

(These are highlighted with brackets in Table 1. It would

3. mo dify the role hierarchy so that role R and R

i j

also b e p ossible to have three distinct sets of one category

inherit from R , and R inherits from the role that R

k k i

each; two are used simply to demonstrate the pro cedure.)

and R previously inherited from.

Because all of the numb ers asso ciated with privilege sets

have c;2 bits, each privilege set will b e lab eled with a

Let

diferent set of categories.

C = total number of categories on the MLS system

4. Rep eat steps 2 and 3 until all privilege sets have

to b e used to implement RBAC.

b een assigned a set of categories.

d = maximum depth of child no des from the ro ot,

where the ro ot is level 0. This is equivalent to the maxi-

L L :binary Categories

1 2

mum level of the leaf no des.

1::2 ; 1 x x x C = c

3 2 1 p j

j jx �1

1 001 c

The categories from C will b e assigned to roles and

2 010 c

privilege sets. If the tree is relatively balanced, then C ;d

3 f011g f c , c g

2 1

categories are available at each level for representing priv-

4 100 c

ilege sets. To distinguish b etween privilege sets, combi-

5 f101g f c , c g

3 1

nations of categories are used. At each level in the tree,

6 f110g f c , c g

3 2

where n is the number of categories available for repre-

7 111 c , c , c

3 2 1

senting roles at that level, the numb er of privilege sets

Table 1.

that can b e distinguished is . Using C ;d cate-

n;2

2.3.3 Assignment of Categories to Roles

gories at each of d levels, the total numb er of privilege sets

in the tree is therefore (dep ending on how well balanced

Each role must b e able to access all privileges asso ciated

C ;d

with its privilege set and all privilege sets asso ciated with

the tree is) approximately .

C ;2d

roles that it inherits, i.e., roles that are represented by an-

cestor no des in the role hierarchy. Categories are assigned

to roles as follows:

2.3.2 Assignment of Categories to Privilege Sets

1. Assign to role R the set of categories assigned to

Privilege sets are asso ciated with categories as follows:

its privilege set.

1. A role at the ro ot of the tree, with privileges avail-

2. For each ancestor role R from which role R inher-

j i

able to all users, is asso ciated with a randomly selected

its privileges, add to the lab els for role R the categories

category. This category is removed from the set of cate-

asso ciated with the privilege set for R .

gories available to designate roles.

2. Roles at level l of the tree, where n indicates the

2.4 Analysis of MLS to RBAC Mapping

numb er of no des at level l , are asso ciated with unique sets

of categories drawn from the set of remaining categories.

MLS systems typically provide 64 to 128 categories for la-

The number of categories needed for level l is the smallest

b eling privileges. The construction describ ed in the pre-

vious section will provide a capability for approximately

number c such that n : . Cho ose c categories

c;2

C ;d

roles. Tables 2 and 3 show the number of

from the remaining set of categories. Remove these c

C ;2d

categories from the set of categories available to designate

roles that can b e controlled for various combinations of

roles.

depth and breadth (branching factor) of role hierarchies.

3. From the set of c categories chosen in step 2, assign

Depth Max. Branching Factor Max. Roles

a unique set of categories to each privilege set at level l .

Step 2 ensures that there are enough categories to make 924 6 x 10 5

all the sets diferent.

1 x 10 20 10

One way of implementing this step is to generate a 4:7 x 10 6 15

list L of numbers from 1 to 2 ; 1, then extract from this

3:4 x 10 3 20

list a second list L containing all numbers whose binary Table 2. Number of Roles Supp orted with 64

representation contains c;2 bits. Each bit is asso ciated Categories

Depth Max. Branching Factor Max. Roles

straints exist on the ability to assign roles to sub jects

5 5,200,300 3:8 x 10

without violating MAC rules.

10 924 4:5 x 10

One advantage of the approach describ ed in this pa-

15 70 4:7 x 10

p er is that it allows RBAC to b e op erated simultaneously

20 20 1:0 x 10

with MAC. Because the roles-to-categories construction

25 10 1:0 x 10

allows the implementation of a large role hierarchy with a

30 6 2:2 x 10

relatively small numb er of categories, the remaining cat-

40 3 1:2 x 10

egories can b e used to implement the traditional multi-

Table 3. Numb er of Roles Supp orted with 128

level security mo del. If the RBAC system do es not embed