SACM: Stateful Access Control Model

Andre L. M. dos SantosState University of Ceara

Fortaleza, Ceara, Brazil

Email: andre@dossantos.org

Vincent ScarlataINTEL

Santa Clara, USA

Email: vincent.scarlata@intel.com

Anderson C. Lima, Inacio C. Alvesand Davi di C. SampaioState University of CearaFortaleza, Ceara, Brazil

Email:{anderson,inacio,davi}@insert.uece.br

Abstract—Access control mechanisms are a fundamental build-ing block in the construction of secure computing environments;however, most of the research in this area has been spent ontraditional access control needs. These models were sufficient inclassical computing systems such as databases and file systems,but as we continue to find new and innovative ways to utilizemobile computing systems these approaches are becoming in-adequate. The primary difference between many of these newpolicies and traditional policies is the need to maintain stateacross transactions. An example of such a policy is a printer kioskthat allows printing only if the traveler has not printed more thansome n pages. Currently, systems with these types of needs arecontrolled by ad-hoc, custom designed systems, rather than ageneralized access control model that is able to express them.Traditional models also typically lack the ability to dynamicallychange. That is, traditional rule sets cannot express policies thatrequire rules to be capable of creating new rules, or deletingold rules. The ability to dynamically produce and delete rulesallows for an additional degree of state to be stored in the model.In this paper, we present the Stateful Access Control Model(SACM), which is designed specifically for these new paradigmsand provides both these new capabilities. It supports usage intraditional centralized systems where access control informationis stored on a computer, as well as a new approach where accessrules are distributed across mobile devices.

Index Terms—Security, Police Language, RBAC, TRBAC,DACM, SACM, Chinese Wall, stateful, Pervasive, Dynamic.

I. INTRODUCTION

Access control mechanisms are a fundamental building

block in the construction of secure computing environments.

Researchers have studied mechanisms for evaluating autho-

rization criteria for decades. Most of this effort, however,

has been spent on a class of access control models that

were originally designed for the needs of servers and tradi-

tional workstations. These models were sufficient in classi-

cal computing systems such as databases, file systems, and

other similar systems, but as we continue to find new and

innovative ways to utilize mobile computing systems these

approaches are becoming inadequate.With increasing research

being conducted on pervasive computing environments, mobile

computing platforms are becoming more instrumental in the

future of computing.

The primary difference between many of these new poli-

cies and traditional policies is the need to maintain state

across transactions. In addition to the limitations imposed on

traditional models by their statelessness, traditional models

typically lack the ability to dynamically change. This ability to

dynamically produce and delete rules allows for an additional

degree of state to be stored in the model. In other words a

small number of generalized rules could produce rules for

large numbers of actions on a need basis, rather than requiring

that they all be created in advance. To our knowledge there are

no generalized models proposed with dynamic characteristics

to this level.

In this paper, we present the Stateful Access Control Model

(SACM). This model is designed specifically for these new

paradigms. It supports usage in centralized systems where

access control information is stored on a computer or server, as

well as a distributed model where this information is stored in

protected areas of mobile devices. SACM utilizes ideas from

policy languages in order to be expressive, while also being

extensible, stateful, and dynamic.

In section II, we give an introduction to the previous work in

access control models. In section III we define the underlying

dependencies of the system and its components. We then give

examples of rule sets for various traditional access policies as

well as new, non-traditional policies in section IV. Finally, we

close with a summary of our conclusion in Section V.

II. BACKGROUND

This section contains an overview of previous research,

which has been conducted to develop access control models

appropriate for the various types of services that computing

systems can provide. We start by discussing traditional models,

and then proceed by discussing important characteristics of

models, how they have been achieved in the past, and how

they relate to our proposed model.

A. Traditional Models

One of the most fundamental access control models is the

Harrison-Ruzzo-Ullman model [7]. This model offers a matrix

of named subjects and named objects, where each cell contains

the permissions for that subject on that object. This model

is very appealing due to its simplicity. However, this same

simplicity is why they are no longer sufficient for current

security needs.

This model is based on the needs of legacy systems where

the assumption is that the subject owns data, and therefore

should be permitted to access it. In corporate environments, it

is the corporation that typically owns the data, and a subject

is given access to the data not based on that subject but rather

their job classification or service type. Typically, Operating

Systems implement this model in form of Access Control List

36th Annual IEEE Conference on Local Computer Networks LCN 2011, Bonn

978-1-61284-928-7/11/$26.00 ©2011 IEEE 159

(ACL) or Capability List (CL), additionally ACLs and CLs are

unable to provide support for the least privileges requirement

of many security models. These two issues gave rise to the

Role-Based Access Control model (RBAC) [6], [9].

The RBAC model is an extension of the access matrix

model with the addition of a new type of meta-subject called

a role. RBAC then dictates which roles should have access

to an object rather than which subjects, and then subjects are

classified by the roles they are permitted to take on. Bertino et

al. expanded upon the RBAC model and proposed a Temporal

RBAC model (TRBAC) [3], [8]. This model extended the

traditional RBAC model to include temporal constraints rather

than the static access of traditional RBAC.

B. Dynamic Rule Creation

Deng et al. [5] proposed a model, called the Dynamic

Access Control Model (DACM), which added some dynamic

features to object oriented systems. However, in this system

rules were dynamically generated from underlying tables that

were still fully maintained by an administrator. Though, even

in this model, the rules are not powerful enough to create rules

of their own as a truly dynamic system could.

This level of dynamics can be valuable for a variety of

policies. We propose that a dynamic rule-based system like

ours can easily accommodate a policy that can creating a

global rule, which will create rules for each subject/event

pairing, on a need basis. That is, during an attempted purchase,

if there does not exist a rule providing an individual with their

n tickets for the current event yet, the global rule will create

one. If there is such rule, then the global rule has already

created it previously and does nothing. Moreover, after the

event passes, each rule created by the global rule, could expire

and thus be deleted automatically.

A generic rule is used to create specialized rules as they

are needed and only if they are needed. In fact, generic rules

can even create new generic rules enabling dynamic changes

of policies. This type of dynamic rule generation opens new

paradigms for intelligent access control models.

C. Stateful Access Controls

The models mentioned previously were all stateless in that

a decision to grant access never affects the next request for

authorization, with the exception of possible account lockout

after excessive failures. Brewer and Nash [4] proposed the

Chinese Wall model, which maintains limited state as a basis

for future authorizations. In this model, objects are split into

classes of conflicting interests, such as financial information

regarding two competing companies. Once a particular subject

accesses an object in one class, that subject is no longer

permitted to access any objects in classes that it conflicts with.

This model requires that the access control store the fact that

a given class has been accessed and reject access to other data

based on it.

While, the Chinese Wall provides a novel aspect to access

controls, the state stored by the model is very limited. We

propose that a more general capacity to provide state would

be useful. In our previous work [1], we briefly describe a

framework for complex ACLs for the Secure Areas of Com-

putation (SAC) Approach [2] safe mobile computing. This

model first introduced the use of counters to create a stateful

access control model. By using counters, a much higher level

of granularity of state can be stored, than in models like the

Chinese Wall. SAC is designed for mobile applications such

as the use of smart cards for banking, libraries, movie rentals,

and other similar environments where a transaction may be

granted or revoked based on previous transactions.

III. SACM BUILDING BLOCKS

In this section, we introduce the general approach our model

takes, as well as some of the building blocks that it is based

on.

A. Approach

There are two primary aspects of SACM that describe its

approach. The first is what type of relations or rules it bases

decisions on and the second is where this information is stored.

With respect to the first aspect, SACM is basically a

policy language. This is because policy languages provide

the specification richness needed for our model. However, our

model is centered around stateful information which applies

to the subject on a per object basis. The model organizes it’s

information into sets of rules that apply to a given object

and subject. These rules store stateful criteria for which

authorization decisions should be based in the form of flags,

variables, and policy elements.

From an organizational stand point, SACM can store its

rules using two different approaches, centralized and decen-

tralized. The centralized approach is the traditional access

control approach. Access control information is stored on the

machine which owns the resource in question or an central

authentication server. This information can be stored with the

subject, the object, or in single database. This approach is very

well suited for most traditional computing environments and

leaves a great deal of control in the hands of the administrators.

However, this approach requires a complete infrastructure, and

does not function well in offline systems, such as the example

in IV-C with the offline printer kiosks.

The opposite approach is to distribute the access control

rules, storing them in tamper resistant area on mobile devices.

In the absence of tamper-proof devices, this model is only

appropriate for systems where the cost of breaking the device

storing the rules is more than the value of the goods or services

to be gained. Printing services, movie rentals, access to gyms,

digital libraries and many similar systems fit into this category.

In these environments and many environments proposed by

pervasive computing and higher mobility the cost savings for

not building an infrastructure outweighs the risk of breaking

a TPM or smart card, since it allows highly distributed offline

usage like printer kiosks scattered throughout airports around

the country.

160

B. General Structure

In the model, each subject has a token counter correspond-

ing to each object it might attempt to access. Each object

also has a set of rules, which operates on its counter. When a

subject attempts to access an object, the appropriate rules are

evaluated.

Each rule is composed of a token counter, two flags, a

set of variables, and policy elements. The first flag, dirty,

determines whether or not the rule is still valid. The second,

auth, determines the result of the authorization decision. If

the auth flag is not set during the execution of rules, the

authorization decision is based on the value of the token

counter. Non-negative values indicate success, while negative

token counters result in failed accesses. In addition, to the

number of tokens in the token counter, rules may also make

use of variables defined within the rule, or arguments presented

at the time of the access check. The policy elements that glue

these pieces together will be described in detail in the next

sections.

C. Object Hierarchy

Objects or services that the system makes authorization

decisions on are assigned a name and arranged into a hierarchy,

which is rooted at a system object and further specifies the

object at each level. This hierarchy is very similar to the class

hierarchy in object-oriented programming languages.

Each of object in the hierarchy has its own set of rules,

which manipulate the object’s token counter. Within each

object’s rule set, rules are separated into different access types

for that object.

D. Authorization and Evaluation

Authorization decisions are evaluated by traversing the

object hierarchy. The evaluation begins at the root object, and

proceeds down to the object being accessed. At each level all

rules corresponding to the requested access type are evaluated.

If no rules exist in the path to the object, the access fails,

otherwise all rules on the path are evaluated. If at any level

the number of tokens is a negative value, authorization fails. If

the evaluation results in a non-negative token count at every

level down to the object being accessed, access is granted.

However, if a rule sets the Auth flag, this will override the

tokens and determine whether authorization is granted without

further execution.

Failed and incomplete executions should not be able to

hinder future accesses or leave the model in an inconsistent

state. Therefore, during evaluation, changes in stored values

such as token counts and variables are not committed unless

the authorization succeeds. That is, the system must not make

any permanent changes to the rule set values, until it has

determined that the attempted action will take place.

IV. USAGE EXAMPLES

In this section, we show the versatility of SACM by con-

structing rules for a variety of access policies, both traditional

and modern.

A. Static Access

The subject is granted access under all circumstances, or is

always rejected. This is the model of most traditional ACL or

RBAC systems, where a subset of subjects or roles have some

static access privileges. Let’s consider an example for read

access to the object named /fileserver/users/data1, which is

some specific file on a disk. We will assume that our example

policies do not expire, unless the policy requires it, although

it should be clear how this can be changed by adding an

expire condition. The rule, which accomplishes this policy,

given our assumptions, is the trivial rule. This rule that has

no if-then action, and is shown below. This is the trivial rule

where a subject is either given 1 or -1 token when the rule set

is initialized. Recall that the authorization is determined by

whether or not the token count is non-negative after executing

the entire rule set. Thus, if -1 tokens were given or no rule

exists at all, the authorization will always fail, refusing the file

read request. If 1 token was given, as is depicted below, the

result of this rule’s execution will always be a non-negative

number of remaining tokens, thus authorizing the read request.

rule ( / F i l e s e r v e r / Use r s / Data1 , Read , 0){initialize ( ( Tokens , 1 ) )

}

B. Temporal Access

An employee is permitted to enter the building only during

the working hours between t0 and t1. The trivial rule from

Section IV-A is used, however an if-then has been added. We

use the method, shown for Door1, to exhibit how multiple

conditions can be used.

rule ( / c s B u i l d i n g / F l o o r 2 / Door1 , Open , 0){initialize ( ( Tokens ,−1) , (var0 , t0 ) , (var1 , t1 ) )if ( TimeT%86400>var0 ) and ( TimeT%86400<var1 )then ( Auth= t r u e )

}As the rule set for Door1 is evaluated, the first condition,

(TimeT%86400 > var0), will test that the current time is later

than the value of the first user variable, which was initialized to

t0. The second condition, (TimeT%86400 < var1), tests that

it is earlier than the second variable, which was initialized

to t1. Note that the rest of the division TimeT/86400 is used

to define the time of the day in seconds where 86400 is total

number of seconds in one day. Actually, this is needed because

TimeT represents the number of seconds since 00:00:00 UTC,

January 1, 1970. Doing this, TimeT%86400 is the real time

in seconds for the current day. If both of these conditions are

true, the action, (Auth = true), hard sets the authorization to

true, which grants access regardless of the token count. If this

condition fails, the negative token count will reject access.

C. Counter Access

An airport in the near future may provide blue tooth printing

services to business travelers. For cost savings, these printers

will not be networked and may be distributed in kiosks

throughout the airport. A traveler creates an account at the

161

service desk and is allowed to print n document pages from.

Once an account is activated, each time the traveler prints a

document from any printer in potentially any airport, the page

count (arg1 or execution-time argument 1) for that document

is debited from the account. A user then buys more credits as

they are needed.

rule ( / T r a v e l l e r S e r v i c e s / P r i n t K i o s k s , Add , 0){initialize ( ( Tokens , 0 ) )Action ( Token += arg1 )

}rule ( / T r a v e l l e r S e r v i c e s / P r i n t K i o s k s , P r i n t , 0 ){

Action ( Token −= arg1 )}

The user initially has 0 tokens. The Add rule is then used

to purchase additional tokens by passing the number of added

tokens as the first execution-time parameter. The action of

this rule, (Token += arg1), simply adds arg1 to the tokens

remaining. When the user attempts to download from the

site, the print rule will decrement the number of pages from

the tokens remaining.

D. Automatic Event Ticket DistributionIn a university system students and faculty are often allowed

n free or discounted tickets for each event. We create a rule

hierarchy such that all events are children of a /Events/ object.

A rule producing rule is inserted at this root, which then

executes on all event ticket purchases. The if-then checks if

there exists a rule for the specific event e, which as a child

of Events will be /Events/e. If it does not, this is the first

ticket purchase attempt for this event, and it inserts a rule

for this event, which will expire after the event date, de. The

rule for each event is then a simple counter rule from Section

IV-C. It’s important to realize that each object in the hierarchy

has its own token counter, so each event /Events/e has its own

token counter, since each event has its own number of available

discount tickets.

rule ( / Events , buy , 0){if ( RuleT� ( / E v e n t s / e , buy , 0 ) ) then

( R u l e S e t i n s e r trule ( / E v e n t s / e , buy , 0 ) {initialize ( ( Tokens , n ) , (var0, de ) )expire ( DateT > var0 )Action ( Tokens − = 1 )

})

}

E. Chinese WallThe Chinese Wall model, as described in Section II, divides

objects into classes based on conflicts of interest. In this

example, we define two conflicting classes, class-A and class-B. Initially, the user has access to each class. We use a simple

positive token to give unconditional access. However, we use

the hierarchy similar to Section IV-D in order to place a rule

that affects all class-A objects and another that effects all class-B objects. This rule when executed will create a rule in the

conflicting class that hard sets Auth to false for every access.

rule ( / F i l e s e r v e r / c l a s s−A, read , 1){initialize ( ( t okens , 1 ) )if ( RuleT� ( / F i l e s e r v e r / c l a s s−B , read , 0 ) ) then

( R u l e S e t i n s e r trule ( / F i l e s e r v e r / c l a s s−B , read , 0){

Action ( Auth = f a l s e )}

)}rule ( / F i l e s e r v e r / c l a s s−B , read , 1){

initialize ( ( t okens , 1 ) )if ( RuleT� ( / F i l e s e r v e r / c l a s s−A, read , 0 ) ) then

( R u l e S e t i n s e r trule ( / F i l e s e r v e r / c l a s s−A, read , 0 ) {Action ( Auth = f a l s e )

})

}

V. CONCLUSION

In this paper, we propose new features of access control

models that will provide for a new paradigm of access control

policies in currents days and are not covered satisfiers. They

accommodate policies that require stateful information about

previous transactions in order to make authorization decisions.

We show the value of maintaining state through counters and

dynamic rule modifications in new mobile environments being

proposed by ubiquitous and pervasive computing. These new

capabilities will allow policies, previously not expressible, to

be expressed in a generalized access control model, rather than

customized ad-hoc solutions. We propose the Stateful Access

Control Model (SACM) as a model that includes these new

features. Additionally, this new model is capable of utilizing a

currently rarely leveraged feature of mobile computing, which

is the ability to distribute access control information in pro-

tected devices. Through example policies and corresponding

demonstration rule sets, we display the versatility of our model

to represent a variety of new paradigms as well as existing,

traditional policies.

REFERENCES

[1] A L. M. Santos and R A. Kemmerer Safe Areas of Computation forSecure Computing with Insecure Applications, Computer SecurityApplications, 1999. ACSAC ’99. 15th Annual Conference

[2] A L. M. Santos and R A. Kemmerer Implementing Security PoliciesUsing the Safe Areas of Computation Approach, Computer SecurityApplications, 2000. ACSAC ’00. 16th Annual Conference

[3] E Bertino, P A Bonatti, and E Ferrari, TRBAC: A temporal role-basedaccess control model, ACM Transactions on Information and SystemSecurity (TISSEC), v. 4, n. 3, pp. 191233, 2001.

[4] D Brewer and M Nash, The Chinese Wall Security Policy, Proc. ofIEEE Symposium on Security and Privacy, pp. 206214, 1989.

[5] P Deng, C Kuo, and V Kao, A dynamic access control model for object-oriented system, pp. 159163, 1993.

[6] D Ferraiolo and R Kuhn, Role-based Access Controls, Proc. of the15th National Computer Security Conference, pp. 554563, 1992.

[7] M A Harrison, M L Ruzzo and J D Ullman, Protection in operatingsystems, Communications of the ACM, pp. 461–471, 1976.

[8] J B D Joshi, E Bertino, and Arif Ghafoor, Temporal hierarchies andinheritance semantics for GTRBAC, Proc. of the 7th ACM Symposiumon Access Control Models and Technologies, pp. 7483, 2002.

[9] R Sandhu, E Coyne, H Feinstein and C Youman, Role-based accesscontrol models, IEEE Computer, v. 29, n. 2, 1996.

162