Citation
Voting-enabled role-based access-control model for distributed collaboration

Material Information

Title:
Voting-enabled role-based access-control model for distributed collaboration
Creator:
Manian, Vijay ( Dissertant )
Newman, Richard E. ( Thesis advisor )
Place of Publication:
Gainesville, Fla.
Publisher:
University of Florida
Publication Date:
Copyright Date:
2005
Language:
English
Physical Description:
x, 95 p.

Subjects

Subjects / Keywords:
Access control systems ( jstor )
Cogs ( jstor )
Computer programming ( jstor )
Computer technicians ( jstor )
Decision support systems ( jstor )
Land access ( jstor )
Mathematical sequences ( jstor )
Modeling ( jstor )
Multilevel models ( jstor )
Voting ( jstor )
Electronic voting ( lcsh )
Computer and Information Science and Engineering thesis, Ph.D ( local )
Computer networks -- Access control ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering ( local )
Teams in the workplace -- Data processing ( lcsh )

Notes

Abstract:
This dissertation presents a voting enabled role-based access control (RBAC) model designed for distributed collaboration that allows the group to decide and implement group policies. This model can also be used in many middle-level systems that require support for group voting. The primary goals of this model are security, scalability, flexibility and simplicity. One of the major drawbacks with many models in use today is the need for an external administrator or a user with "god-level" powers to implement the group policies. We overcome this by allowing subsets of users to vote on access control decisions that are deemed important. This takes the burden of group management from the system administrators and allows the group to be truly democratic and autonomous. In this dissertation, we give the motivation for the model, formally define it and give an example of how it can be used. We also define the access right leakage problem which we use to analyze the safety of the model. We first prove that for a simple version without any voting, the access right leakage problem can be decided in polynomial time. We then introduce the notion of trust-level and discuss how the trust-level of the users affect the safety of the system. This dissertation identifies three simple approaches by which a malicious entity can cause group members to vote in a manner that is not in the best interest of the group. We then analyze the safety of the model under each of these three approaches.
Subject:
access, collaboration, trust, voting
General Note:
Title from title page of source document.
General Note:
Document formatted into pages; contains 105 pages.
General Note:
Includes vita.
Thesis:
Thesis (Ph. D.)--University of Florida, 2005.
Bibliography:
Includes bibliographical references.
General Note:
Text (Electronic thesis) in PDF format.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Manian, Vijay. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
4/17/2006

Downloads

This item has the following downloads:


Full Text











VOTING ENABLED ROLE-BASED ACCESS CONTROL MODEL FOR
DISTRIBUTED COLLABORATION















By

VIJAY MANIAN


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2005
















I dedicate this work to my parents, S.V.S. and Padma Manian.















ACKNOWLEDGMENTS

I would like to thank Dr. Richard N. vin i, for getting me started on this

project. I would like to express my gratitude to Dr.Steve Thebaut for his willing-

ness to help me whenever I had a problem. I would also like to thank all the DCS

group members, past and present, for their invaluable contributions without which

I would not have been able to complete this dissertation.

Special thanks are due to Salil Gokhale for helping me stay on track during the

last stages of my Ph.D. Finally, I would like to thank my parents for their support

and encouragement.















TABLE OF CONTENTS
page

ACKNOWLEDGMENTS ................... ...... iii

LIST OF TABLES ...................... ......... vii

LIST OF FIGURES ................... ......... viii

ABSTRACT .............................. ..... ix

CHAPTER

1 INTRODUCTION .................... ....... 1

1.1 M otivation . . . . . . . 2
1.2 Sample Scenario ............................ 4
1.3 Organization of this Dissertation ......... ......... 6

2 DCS OVERVIEW .............................. 7

2.1 Introduction . . . . . . . 7
2.2 D efinitions . . . . . . .. . 8
2.3 A Typical Day at Work ................... ... 9
2.4 Services .................. ............. .. 10
2.4.1 CoG Manager (C\!) .................. .... 10
2.4.2 Notification Services (NTF) ................. .. 10
2.4.3 Database Services (DBS) .................. .. 12
2.4.4 Decision Support Service (DSS) .............. .. 12
2.4.5 Access Control Services (ACS) ............... .. 12
2.4.6 Secure Communications Services (SCS) . . 13
2.4.7 Distributed File Services (DFS) .............. 13
2.4.8 Application Manager (AM) ................. .. 14
2.4.9 Tools .................. ........... .. 14
2.5 Interaction With Other Services .................. .. 14
2.5.1 Interaction With DBS ................ .. .. 15
2.5.2 Interaction W ith C'\I ................ .. .. 15
2.5.3 Interaction With DSS ................ .. .. 15
2.6 Summary .................. ............ .. 15

3 BACKGROUND ............... ........... ..17

3.1 Introduction ............... ........... ..17
3.2 Access Control. .................... ......... .. 17









3.3 Access Matrix Models ................ ... ... .. 18
3.3.1 HRU Model ............... ....... .. 19
3.3.2 Typed Access Matrix ...... .......... ... 20
3.3.3 Access Control in UNIX Operating System . ... 23
3.4 Role-Based Access Control (RBAC) .... . . 25
3.5 Distributed Compartment Model ... . . 26
3.6 Access Control for Collaborative Environments . .... 28
3.7 Trust and Voting ............... ........ .. 30
3.8 Summary ............... ......... .. 31

4 THE DCS-AC MODEL .............. . .. .. 33

4.1 Introduction ............... ........... .. 33
4.2 The DCS-AC Model ................ ... ... .. 33
4.3 Operations ................. ........... 36
4.4 Commands in DCS-AC Model ............. .. .. .. 39
4.4.1 Constraints. ....... ............ ..... 41
4.4.2 Expressive Power ............... .... 43
4.5 Comparison with existing models ............. .. .. 44
4.6 Features of DCS-AC Model ................ ...... 45
4.6.1 Decision Templates ................ . 46
4.6.2 Dynamic Type Binding ............. . .. 47
4.6.3 Dynamic set of Access Rights .... . . 47
4.6.4 Dynamic set of Object Types .... . . 48
4.6.5 Fine Grain Access Control .... . . 48
4.7 DCS-AC Model Solution for Software Project Example . 49
4.8 Summary ............... ......... .. 51

5 SAFETY ANALYSIS .................. .......... .. 52

5.1 Introduction ............... ........... .. 52
5.2 Definitions ............... ........... .. 52
5.3 Attributes of a State ................ ... .... .. 54
5.4 Proofs ............... ............. .. 55
5.5 Summary ............... ......... .. 68

6 TRUST AND VOTING ............... ........ .. 69

6.1 Introduction ............... ........... .. 69
6.2 Trust and Trust-Worthiness ............... .... 69
6.2.1 Approaching Trust ...... ......... .... 70
6.2.2 Decision Templates ................ . 72
6.3 ARL Problem And States ................ . 74
6.4 Trust Analysis of DCS-AC ................ ...... 75
6.4.1 State Graph .... ........... .... 75
6.4.2 Ad-Approach. .............. ... ... .. 77
6.4.3 Pay-As-You-Go Approach .... . 79









6.4.4 Honest Politicial Approach ................. .. 80
6.5 Summary ............... ......... ..82

7 NEXT STEPS ................ ........ ....... 84

7.1 Enhancing DCS Commands ............... .... 84
7.2 Special Relations ............... ........ ..85
7.3 Role Hierarchy ............... .......... ..85
7.4 Use-Cases and Scenarios ..... .......... .... 86
7.5 Multi-User Collusion Attacks ...... .......... .... 86
7.6 Time-Limited Access ................ ... .... .. 87

8 CONCLUSION .................. ............ .. 88

REFERENCES ............. .. ............ ... 90

BIOGRAPHICAL SKETCH .............. . .. 95















LIST OF TABLES
Table page

3-1 Primitive Operations in HRU model .................. 19

3-2 Primitive Operations in TAM model .................. 21

4-1 Example of DCS-AC Matrix Fragment ................. ..36

4-2 Specification of DCS-AC Operations .................. 37

4-3 DCS-AC Solution for Software Project Example ........... ..50















LIST OF FIGURES
Figure page

1-1 Class Library Scenario .................. .. 5

2-1 Architecture of DCS .................. ..... 11

4-1 Comparison of HRU, TAM and DCS-AC models . ..... 44















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

VOTING ENABLED ROLE-BASED ACCESS CONTROL MODEL FOR
DISTRIBUTED COLLABORATION

By

Vijay Manian

December 2005

C(! ,i': Richard E. N, v in ,
M ii Department: Computer and Informational Sciences and Engineering

This dissertation presents a voting enabled role-based access control (RBAC)

model designed for distributed collaboration that allows the group to decide and

implement group policies. This model can also be used in many middle-level

systems that require support for group voting. The primary goals of this model

are security, scalability, flexibility and simplicity. One of the 1 i, i" drawbacks with

many models in use tod -v is the need for an external administrator or a user with

;od-level" powers to implement the group policies. We overcome this by allowing

subsets of users to vote on access control decisions that are deemed important.

This takes the burden of group management from the system administrators and

allows the group to be truly democratic and autonomous. In this dissertation, we

give the motivation for the model, formally define it and give an example of how

it can be used. We also define the access right leakage problem which we use to

analyze the safety of the model. We first prove that for a simple version without

any voting, the access right leakage problem can be decided in polynomial time.

We then introduce the notion of trust-level and discuss how the trust-level of

the users affect the safety of the system. This dissertation identifies three simple









approaches by which a malicious entity can cause group members to vote in a

manner that is not in the best interest of the group. We then analyze the safety of

the model under each of these three approaches.















CHAPTER 1
INTRODUCTION

Distributed collaboration is more than just a buzzword in .1-'di's world.

Most users log in from large networks, and often times, the collaborators are from

different administrative domains. In such a scenario, access control can become

an additional burden on the already overworked administrators and usually is

difficult without enforcing many restrictions. On a stand-alone machine, access

control is more or less straightforward with the operating system providing simple

discretionary access control (DAC) mechanisms like access control lists (ACL) or

capability lists (CL). Most of these mechanisms are based on the access control

matrix (AC'\l) model [1, 2]. Various models have been proposed for multi-user

systems and these models are defined with well-known abstractions like subjects,

objects and access rights.

There are some i1n i, i"r disadvantages to the current models when applied

to distributed environments in general and distributed collaborative systems in

particular. Most systems tod -v are run over the network and have a centralized

node to handle access control, which results in a single point of failure and more

importantly, a single administrative authority, which is not ahv--, desirable. Many

practical models restrict the types of accesses (for example, Unix has only three

types: read, write and execute), which does not reflect real life. In addition, each

object in the system can have only one owner, which might not be the case in a

collaborative environment. Some of the 1 i jri problems with classical models are

discussed in section 1.1.

The Distributed Conferencing System-Access Control Model (DCS-AC)

discussed in this dissertation has been designed to provide a simple, powerful,









implementable, scalable and flexible access control mechanism. One of the most

important features of this model is the use of group decision-making mechanisms

(voting) as a part of the access control decision process. Here, important access

control decisions can be referred to a vote among a specified subset of the users,

thereby allowing them to self-administer the groups. 1 ii': current models rely

on a -,'I' i i~" ," who can do almost anything in the system. The DCS approach

models society more closely and also protects the system against malicious single-

user attacks.

We analyze the safety of the model in terms of the Access Rights Leakage

(ARL) problem. ARL is the problem of deciding whether a malicious entity can

execute a set of commands which result in an unauthorized user gaining access to

an object in a given DCS-AC instance. We approach this problem by first solving

it for a system with no voting. When the subjects are allowed to vote on one or

more access control decisions, it is difficult to decide on a yes or no answer. We

assign a trust-level value to each subject and decide on the answer in terms of

the trust-levels of all the subjects who can participate in the vote(s). Let us now

consider why we need the DCS-AC model.

1.1 Motivation

Most access control systems in use tod w are based on the traditional ac-

cess control matrix model.1 This proposal considers access control policies in a

distributed collaborative environment where the traditional models suffer from

the following problems (a few more problems with current systems are given in

Greenwald [3]).





1 ACL and CL can be considered to be a part of the traditional access control
matrix model









1. System administrators are usually overworked and underpaid. A centralized
server that coordinates the entire distributed system will not work well.

2. If three subjects are collaborating on a document, under the current
paradigm, any one of these three can unilaterally delete the object. This
is not desirable and a more useful policy could be to require at least two of
the author's approval in order to delete the object.

3. It is difficult to obtain access to objects located in a different administrative
domain without getting the local system administrator's permission.

4. Even in systems that are specifically designed for distributed computing [4],
like grid computing, the standard policy is for each domain to be responsible
for the objects in its site [5]. Now, if Alice accesses an object from another
administrative domain, a < ,v of the object is usually cached. The local
system has no idea about the access control policies of this object and when
Bob requests access to the same object, the request is forwarded to the other
domain. If the local system were aware of the access control policies for the
object, it could have made the decision on its own and saved Bob a lot of
time.

5. The individual groups of collaborators cannot set their own group policies.

The DCS-AC model addresses these issues and provides a very flexible access

control mechanism. This model was developed for Distributed Conferencing System

(DCS) [6], a distributed collaborative architecture that allows users from different

sites to work together. The first objective of the DCS-AC model is to provide

flexible, implementable and fault tolerant access control. The second objective is

to allow the users of the system to self-administer the access privileges, i.e., allow a

subset of users (who are often the stakeholders) to make access control decisions for

important objects on a case-by-case basis. This is done by using a set of decision

templates each of which defines the subset of users that can participate in a vote.

Each entry in the AC'\ has a decision template pointer which has to be exe-

cuted in order to arrive at a decision. Although the model enforces no constraints

on which decisions require a vote, we expect that most entries will point to the

A1l, .;;,--;. template which ahv--, returns a .;/ since many rights, once granted,









need not be referred to the voting group for every access. However, for important

access control decisions the system can refer the decision to a subset of the users

who vote on it. This allows the users to express access control policies for some

accesses (like joining the group, accessing important objects, granting access rights,

etc.) in the system.

The use of decision pointers also improves fault tolerance. It protects against

single malicious user threats, since many users may have to agree for the vote

to pass. In addition, if some of the users are unavailable, the system can still

take decisions based on the users available (unless the system policy specifically

states that a particular user must agree for the vote to pass). There are many

real-life scenarios in which such multi-user authorizations are required and are often

handled off-line before one of the participants "informs" the system if the request is

approved.

1.2 Sample Scenario

Consider the following example of a project to be implemented by a team

consisting of a project leader (PL) and many subordinates (architects, 1i.' i ,ii,,in,, rs

and testers). The architects work on the design and once the design is approved

by the PL, one or more 1' .,.'ii I,,' rs code the project, which is then tested by

the testers. The testers can either send it back to the programmers along with a

bug-list or notify the PL that the code is acceptable. The PL then reviews the code

with the review team, and if approved, the project is released to the client (refer to

Figure 1-1).

Given below are a few

1. The individuals concerned may be located in different branches; confidential-
ity and availability are important for the shared objects.

2. The architect does not need access to the code and the tester can look at the
code only after the programmers are ready.













Problem Statement


Figure 1-1: Class Library Scenario


3. The review team consists of all PLs in the i. "-! ln-: and the members do not
have access to the code until it passes the testing phase.

4. The PL can access any document related to this particular project at any
point of time.

5. The PL also decides who works on this project.

6. The PL cannot change the role of an employee; for example, the PL cannot
assign a programmer to do the task of an architect.

7. There are many architects, programmers, etc. in the company, and only those
involved in development should have access to the objects.

8. The programmers do an internal review and send the code to the testers after
every programmer has approved it.

9. The review team members vote on whether the code can be added to the
library.

The first eight requirements can be handled by RBAC in a straightforward manner

using constraints. However, specifying constraints introduces runtime overhead

[7]. Requirements eight and nine involve group decisions. Although the above

example deals with a simplistic scenario, we believe that there are many examples










that involve similar issues. The DCS model is designed to handle scenarios of this

nature.

1.3 Organization of this Dissertation

C'! lpter 2 gives a brief overview of the Distributed Conferencing System and

chapter 3 provides the technical background for the DCS access control model.

C!i lpter 4 deals with the formal definition of the DCS Model and discusses the

features of the DCS model. Ci Ilpter 5 discusses the decidability of the ARL

problem for the DCS-AC model without voting and chapter 6 discusses trust in

voters and the trust worthiness of a DCS-AC system where voting is allowed.

chapter 7 mentions some future directions of research and chapter 8 concludes this

work.















CHAPTER 2
DCS OVERVIEW

2.1 Introduction

In tod w's highly-networked working environment, support for collaboration

and group-work has become critical. The availability of low-cost Wide Area

Networks (WANs) means that members of a group can be geographically scattered

around the country (or even the world). There is a growing need for efficient

architectures and applications that facilitate collaboration between such members.

A system that allows users to log on from different locations, to share objects, and

to work on the same object with other members of the group has become essential

in such cases.

The Distributed Conferencing System (DCS) seeks to fulfill these requirements

and many more. The system is based on a robust architecture and provides

distributed file services, access control, secure communication, notification and

group decision-making mechanisms. The DCS will provide basic distributed

collaborative applications like text editors, graphics editors, etc., and can also

support third-party applications. The scalable architecture can support multiple

sites and objects can be replicated to ensure faster access and availability. One

of the 1i ii' r design criteria is fault tolerance. The system is designed to handle

network failures and system crashes by restoring from backups and contacting

other sites for the most up-to-date information. We achieve this by replicating

the objects across multiple sites and also by means of backup servers for each site

which can take over if the primary server fails.









2.2 Definitions

Before getting into the details of DCS and the various services provided, we

first define some terms that are required to understand the architecture:


DCS instance This is a collective term for one or more DCS sites that share
resources, communicate DCS specific information with and store information
about each other. Any user id or CoG registered at one site is accessible
from all sites in that DCS instance. An instance of DCS may cover multiple
administrative domains.

Site This term refers to the DCS servers) located in a single administrative
domain that provide services to the users. Sites that are a part of the same
DCS instance can communicate with each other.

Collaborative group (CoG) This term refers to a persistent or transient
group consisting of members, objects, applications, and a DCS-AC system
(consisting of roles, object types, allowable member-role bindings and decision
templates). The members of a CoG work together on the objects and decide
group policies for that CoG.

User This is an entity in the system that initiates action and (in the context
of access control) requests to access objects. This term usually refers to a
human being.

Member This term when used in the context of a CoG refers to a user who
is a part of the CoG and has been granted rights that are not granted to
non-members.

Subject This represents an active user process that is allowed to perform
some action within the system on behalf of the user.

Object This is a passive entity in the system. Users can perform various
accesses on them. Examples of objects are documents, files and DCS system
specific tables.

Application This is a program that the user launches from within the system
to work on the objects.

Collaboration-ware These are applications that are designed to support
collaborative work. Therefore these applications will have a better access
control features than the regular off-the-shelf applications.









DCS-aware applications These are applications that are specifically designed
to work within the DCS. These applications can use the features of DCS like
event notification or new access type registration.

Role This is a named group of subjects. Roles can also be viewed as a
collection of job functions. A particular subject can bind to any number of
roles but at any point of time, the subject can be bound to only one role. It
must be noted that role as used here is slightly different from role as used in
Role-based access control because there is no notion of a role-hierarchy in the
DCS model.

Object type This is a named group of objects. A particular object can belong
to only one object type.

2.3 A Typical Day at Work

A typical instance of DCS consists of many sites and each site consists of a

primary server with one or more backup servers (which are ranked from 1 to n

where n is the number of backups) to ensure high availability. The primary server

sends periodic heartbeats and updates to the backups [8]. If the backups do not

get the heartbeat from the primary for a fixed amount of time, the lowest ranked

backup takes over as the primary and informs the other sites in the instance.

Similarly, the sites exchange heartbeats and if a site does not respond, the other

sites can take over the management of objects controlled by the failed site.

Each site contributes resources (like disk space) to the instance and all objects

are partially replicated to provide fault tolerance. The DCS architecture is divided

in to various modules each of which provides a different service to the users (section

2.4). A user logs into a CoG through a site and is bound to a role (based on the

user-role bindings maintained by the Access Control Services). The Distributed

File Services provides a uniform view of the DCS space, which actually consists of

objects located on different sites. The user can launch applications to access these

objects, participate in decision making processes or interact with other members of

the CoG. It must be noted that site are managed in the same way as CoGs. That

is, On each site, there is a CoG corresponding to the site containing all subjects









who joined the DCS instance from that site; they can form and implement their

own site management rules. The following section provides a brief description of

the various services and tools available in DCS.

2.4 Services

The architecture of DCS v.2 is shown in figure 2-1. It is based on various

services available in most networked domains (like local file systems, TCP/IP,

cryptographic packages, database system, etc.). Since we are using Java [9, 10], the

sites need not all run the same operating system. A brief description of the core

services is given below.

2.4.1 CoG Manager (C\M)

This is the module responsible for managing the collaborative groups (CoGs)

[11]. This module instantiates the other modules and the clients interact with the

other services mainly through the C \!. Tasks like merging two instances of DCS

or sites or CoGs, and splitting an instance, a site, or a CoG is handled by this

module. The C'\ interacts with the secure messaging and the cryptographic 1lV,-i

during user login. The user's access control requests are routed through the C'\ .

The C'\ also allows the user to import and export objects, add new members and

start sub-groups (sub-CoGs).

2.4.2 Notification Services (NTF)

The NTF [12] provides .,-vnchronous event notification to registered users.

Users can define new event types and register to be notified on events. Subjects

are automatically registered for notification if they are among the valid voters

on a decision. The various services and applications running in the instance raise

events as and when they occur and the NTF maintains a global and local database

in which it stores the users to be notified on each event along with the delivery

method.























NTF ACS


Figure 2-1: Architecture of DCS









2.4.3 Database Services (DBS)

The DBS [13] makes use of a backed Database Management System (DBMS)

[14] to maintain the tables of all the DCS services and applications. Most tables

are stored as partially replicated distributed databases. The DBS uses group

multicast and ensures eventual consistency among all member sites by using vector

timestamps. Since DBS uses Java Database Connectivity (JDBC) [15], we can use

any backed DBMS system like MySQL [16] or PostgreSQL [17].

2.4.4 Decision Support Service (DSS)

Decision Support System [18] is a module that facilitates resolving issues by a

group of users who have a joint responsibility to such decisions. Voting is one of the

tools of DSS which is designed to be a flexible and friendly system that allows users

to initiate, participate in and terminate decisions within the context of a CoG. It

provides on-line voting and has automated vote collection mechanisms. It allows

members who are currently off-line to be voters in a decision process. The initiator

of the vote can set time constraints and specify voting parameters, voters, reporting

--1i. and report recipients.

This service takes into account the user's role, weight assigned to the vote and

access rights, etc. It has several features like reminders, request for status, change

of vote, short circuit evaluation, withdrawal and termination of active votes, which

add more flexibility to the decision process. It also allows other modules of DCS to

make these requests.

The module supports different voting methods like 1in i i i ly, plurality, and

ranking. Users can save their requirements as templates that can be reused in the

future by anyone who has the access rights to do so.

2.4.5 Access Control Services (ACS)

The ACS [19], as the name -,-.-- -i- controls access to (CoG-specific or

instance-specific) objects. It makes use of decision templates of the DSS to provide









group decision-based access control. This puts the control of the CoG in the hands

of the members. The ACS stores its tables in a database through the DBS. The

ACS allows applications to register new access types. This allows more fine-grain

access control if the application supports it.

The ACS interacts with all the other five modules and provides various

services to the users. The DCS architecture requires the ACS to allow decisions

to be made on access control requests at the source site itself. This coupled with

the decision templates makes the ACS an interesting study in itself. The model

used here is not specific to DCS and can be used in any distributed system that

supports group decision-making mechanisms.

2.4.6 Secure Communications Services (SCS)

The Secure Communication Services [20] ensures the confidentiality, authentic-

ity and integrity of all messages passed between sites and clients. To enforce these

important security properties, it is necessary to establish the identity of the entities

of the system. The entities of the system are users, hosts, and servers. The identi-

fication of the entities should be done reliably, that is, it should be authenticated.

DCS poses a greater challenge since entities communicate through messages and

hence all the entities must establish their identities and maintain confidentiality. In

DCS, identity is first established using strong authentication and per-connection

symmetric cryptography provides confidentiality and integrity. The SCS is also

responsible for creation and maintenance of keys and certificates for sites and users.

2.4.7 Distributed File Services (DFS)

The Distributed File Services [21] provides a DCS-specific view of the objects

located at various sites. It allows concurrent access of files using a versioning

scheme with immutable shared files and is designed to provide reasonable service

in the case of site crashes. Each CoG is represented by a directory in DCS-space

and sub-CoGs are simply sub-directories under the directory corresponding to the









parent CoG. The DFS creates and maintains multiple copies of all objects, thereby

ensuring high availability.

2.4.8 Application Manager (AM)

The Application Manager is responsible for registering and invoking applica-

tions that are available for each CoG. These applications could be DCS-aware (like

MACE [22]) or DCS-unaware. The AM maintains a list of applications available for

a particular CoG, and depending on the access rights of the user, it makes those

available to the users.

2.4.9 Tools

The DCS framework provides a few basic tools for collaboration. These include

instant messaging (Gossip), concurrent text (\! ACE) and graphics (Ensemble)

editors.


Gossip This is a simple instant messaging application that is a part of the
client GUI. It allows the user to be in touch with his/her collaborators.

MACE MACE [22] stands for Mother of All Concurrent Editors and is
a very powerful concurrent text editor. In addition to regular text editor
features, MACE allows users to lock various parts of the files and share views.
MACE provides a very fine-grained (byte-level) locking mechanism and the
user can set the view rights for others, i.e., the other users can see every key
stroke or receive updates only when the writer commits the changes. This
allows other users to "look over the shoulder" of the writer (useful in pair
programming among other areas).

Ensemble Ensemble is a concurrent graphics editors that provides object-
locking and specific user pointer view. Multiple users can work on the same
figure and each user can lock one or more objects and share cursor, allowing
other users to see exactly what is going on.

2.5 Interaction With Other Services

Since we are primarily concerned with the ACS, which implements the DCS-

AC model, let us look at ACS' interactions with the other services. As mentioned









earlier, ACS interacts with all the core services. Out of these, DBS and DSS

provide vital services required for ACS.

2.5.1 Interaction With DBS

All ACS information about a CoG are stored as relational database tables that

are replicated across all sites interested in the CoG by DBS. When a new CoG is

created, the relevant ACS tables have to be created on the local site. Whenever

a site wants to participate in a CoG, it obtains a dump of the ACS tables from

a site that is already in the CoG and copies it on to the local database. Any

database query can be handled by the DBMS at the local site but updates have to

be forwarded to the site that '.--;" the entry and then multi-cast to other sites.

2.5.2 Interaction With C'\

The C'\I controls the entire conference and instantiates the objects that

provide the services including ACS. Moreover, most user requests are passed on to

the ACS through the C\ i. Most C\ I-originated actions have to be checked through

the ACS for access privileges. For example, if a user wants to import a new file, the

C'\ will have to check with the ACS before proceeding with the import.

2.5.3 Interaction With DSS

The DSS handles the decision-making process and is therefore closely tied to

the ACS. If a request requires a vote, the DSS has to be invoked and the voting

process initiated. The ACS must be able to check the status of a particular vote.

When a vote is completed, the DSS should notify the ACS. Similarly, the ACS

must be able to report a list of active votes to the DSS if the DSS decides to delete

obsolete votes. Actions like defining new templates and modifying existing ones

require a check by the ACS.

2.6 Summary

The core services described here provide a framework for distributed collab-

oration. The three tools mentioned are what we consider minimal applications







16

required by collaborating users. The Application Manager allows users to execute

other applications from within the DCS framework. As will become clear in the

next chapter, DSS is required by the DCS-AC model since it handles all voting

related issues.















CHAPTER 3
BACKGROUND

3.1 Introduction

This chapter surveys some of the work in access control and trust in voters

that is relevant to the Distributed Conferencing Service Access Control (DCS-AC)

model.

3.2 Access Control

Protection of objects is complex because the number of access points may be

large, there may be no central authority through which all access requests pass,

and the kind of access is not simply limited to read, write, or execute. According to

Pfleeger [23], there are several complementary goals in such a mechanism.


C' e. very access. We may want to revoke a user's privilege to access an
object. If we have previously authorized the user to access the object, we do
not necessarily mean the user should retain indefinite access to the object.

Allow least privilege. A subject should have access to the smallest number
of objects necessary to perform some task. Not allowing unnecessary access
to objects guards against security weaknesses if a part of the protection
mechanism should fail.

Verify acceptable usage. The final decision on an access request is a yes-no
decision. Of more interest is checking that the activity to be performed on an
object is appropriate.

Access control policies are broadly classified as Mandatory Access Control

(\!AC) and Discretionary Access Control (DAC). MAC means that access control

policy decisions are made beyond the control of the individual owner of an object.

A central authority determines what information is to be accessible by whom, and

the user cannot change access rights [23]. A classic example of MAC is in military









security where the owner of a "top--- i. I object cannot decide who has top-secret

clearance nor can the owner change the classification of the object to "secret".

Examples of models that enforce MAC include Bell-La Padula Confidentiality

model [24] and Biba Integrity Model [25]. DAC on the other hand, allows the

owner of an object or .iione else who is authorized to control access to the object

to specify who has what access to the object. The access rights in a DAC scheme

can change dynamically [23]. One of the main differences between DAC and MAC

is the fact that MAC is also concerned with the flow of information [26].

In this work, we are mainly concerned with DAC since we want the users to

be able to decide their own access control policies without .,vii, central authority.

In the following sections we look at various protection mechanisms. First we will

consider the Access Matrix model. We also describe certain modifications like

Access Control Lists and Capability lists along with the Graham-Denning and

Harrison-Ruzzo-Ullman models, which are all DAC models. Next we will review

role based access control, and the Distributed Compartment Model for resource

management and access control proposed by Steven Greenwald. Finally, we will

look at recent work on access control for collaborative environments.

3.3 Access Matrix Models

Access control matrices are the most popular means of modeling an access

control system. An access control system has a group of users, objects and access

rights for those users on those objects. The HRU [27] and Graham-Denning [2]

models are early examples of such models. Such systems have a set of commands

that test the presence of various rights in the matrix and then execute a sequence

of operations. Most modern systems use a variation of the access control matrix

like access control lists or capability lists. Access rights leakage is an interesting

property of access control systems. One of the many means of analyzing a model is

to try to classify the leakage problem for that model.









Table 3-1: Primitive Operations in HRU model

enter r into (X, Xo)
delete r from (Xs, Xo)
create subject X,
create object Xo
destroy subject X,
destroy object Xo


3.3.1 HRU Model

Harrison, Ruzzo and Ullman proposed a model in 1976 that is popularly

referred to as the HRU model [27]. A HRU protection system consists of a static,

finite set of rights R, and a static, finite set of commands, C. There are six

primitive operations defined which are given in Figure 3-1. A configuration of a

protection system is a triple (S, O, P), where S is the set of subjects, O is the set

of objects, S C 0, and P is a rights matrix, with a row for each subject and a

column for each object. P[s, o] (C R) gives the rights to the object o possessed by

the subject s. The formal definition of the model is as follows:

D [i../ A protection I.' ,,, consists of the following parts:


1. a finite set of rights, R,

2. a finite set C of commands of the form:
command a(Xi,X2,..., Xk)
if (ri E (X,i,X1o)) A... A (rm E (Xsm, Xo)) then
opi

opn
end

Here each subject or object Xsi or Xoi is one of the parameters Xj and each

operation opi is one of the primitive operations given in Table 3-1.

Access right Leak

While we cannot expect a useful system to be safe in the strictest sense, the

minimum tolerable situation is that the user should be able to decide whether a









given configuration could lead to some other user getting a specific right, i.e., if

the right leaks to other users [27]. Needless to -'v, there are some users whom we

trust and in fact expect to have the right. We remove the rows corresponding to

those users and try to find out if the right leaks when some sequence of commands

is executed. The formal definition of the safety question for access control systems

is given below:

Definition Given a protection system, we ~v- a sequence of commands ca, ca2,.. *

leaks a right p from a starting state Q if the commands when run on Q (in se-

quence), can execute a primitive operation that allows some user the right p that

was not allowed Q.

In other words, a system leaks a right p if and only if it is possible for an

unintended subject to get the right p on an object o by the execution of a sequence

of commands. The authors have proved that the safety question (also called access

right leakage problem) is generally undecidable for the HRU model. It is interesting

to note that if we enforce the mono-operation restriction, i.e., each command can

execute only one of the primitive commands, then the safety question for such a

system is NP-complete. However, most useful HRU systems cannot satisfy the

mono-operation requirement.

The Typed Access Matrix (TAM) model [28],[29] adds strong typing to the

HRU model. The access rights problem for the generic TAM model has been

proven to be undecidable but there are certain restricted versions of TAM for which

the problem has been proven to be NP-Hard.

3.3.2 Typed Access Matrix

Ravi Sandhu and others have worked on modifying the HRU model to make

the safety problem decidable while at the same time maximizing the expressing

power [30]. The Typed Access Matrix (TAM) [28] defined by Sandhu combines

strong safety properties for propagation of access rights of Schematic Protection









Table 3-2: Primitive Operations in TAM model

enter r into [X, Xo] delete r from [X, Xo]
create subject X, of type t, delete subject X,
create object Xo of type to delete object Xo


Model [31] with the natural expressive power of the HRU model. TAM is obtained

by incorporating strong typing into the HRU model [29]. It is important to

understand that the types and rights are specified as part of the system definition.

The system administrator specifies the following sets for this purpose:


a finite set of access rights denoted by R, and

a finite set of object types denoted by T.

The protection state is a TAM system is given by the four-tuple (OBJ, SUB, t,

AM) interpreted as follows:


OBJ is the set of objects.

SUB is the set of subjects, SUB c OBJ.

t : OBJ -- T, is the type function which gives the type of every object.

AM is the access matrix. We have AM[S, O] C R where S is a subject and
O is an object.

The protection state of the system is changed by means of TAM commands. Each

TAM command has the following format:

command a(XI : t, X2 : t2, ... ,Xk : tk)

if ri E [X,,, Xo1 A r2 [X,,, X2] A .-A r E [X,, XX0

then opi; op2;...;,''

end

Here a is the name of the command; Xi are formal parameters whose types are

ti; ri are rights. Each opi is one of the primitive operations listed in table 3-2.









The rights, types and commands define the system scheme. The scheme can

be modified only by the system administrator, who is not considered to be a part

of the system. The type of an object is fixed and cannot be changed within the

system. Sandhu has proved that TAM has considerable expressive power.

Safety problem in TAM

The access rights leakage problem for the general TAM model is undecidable

(refer to the original paper [29] for proof). The author defines a few restrictions

on TAM that allow us to make the problem decidable. A TAM system that does

not have any command that deletes a right or destroys a subject or object is called

Monotonic TAM. In such a system, S, O and P[s, o] are all monotonically non-

decreasing. In a given command a, we i- that a type ti is a child type in that

command if one of the following primitive operations create subject Xi of type

ti or create object X, of type ti occurs in the body of a. The type tj is said

to be a parent type in a if one of the parameters of a is of type tj and tj is not a

child type in a. The creation 'jr'l, of an TAM scheme is a directed graph with

vertex set T and an edge from u to v if and only if there is a command in which

u is a parent type and v is a child type. A TAM scheme is .: if and only if

its creation graph is .,1 i-, 1i A Ternary TAM is identical to TAM except that all

commands are limited to a maximum of three parameters. Given these properties,

Sandhu has proved the following results:


1. Generic MTAM is undecidable.

2. Acyclic MTAM is NP-Hard.

3. The safety question for .,- i-* i- ternary MTAM is decidable in polynomial
time in the size of the initial access matrix.









3.3.3 Access Control in UNIX Operating System

The UNIX operating system was developed at Bell Laboratories in the late

1960s. It evolved in a "friendly" environment, on systems that encouraged users

to share their files [32]. However, UNIX is by design a very robust system. The

following is a brief discussion of the basic principles in UNIX access control.

Files are central to UNIX in v- -, that are not true for other operating

systems. Commands are executable files in specific directories like /bin, /usr/bin,

etc. System privileges and permissions are controlled in a large part via access to

files [33]. Access to files is organized around file ownership and protection.

Each file has a user owner and a group owner. UNIX supports three types of

file access: read (r), write (w), and execute(x). A different set of access rights can

be set for user owner, group members and others. For example, the access right

rwxr xr means that the user owner can read, write and execute the file,

members of the group owner can read and execute the file but all others can only

read the file. The command that is used to alter the access mode is chmod.

There are a few other defined file modes, namely, t (Sticky bit, keep executable

in memory after exit), s (Set process user ID or group ID on execution), and I (set

mandatory file locking on reads/writes). Files that begin with a period are hidden

files and are not listed by Is command unless used with the -a option. The -1

option of Is command lists the files along with the modes and owners of the files.

The set of commands that are used to modify the access rights of files are:


chmod Specify the protection modes for files.

umask Specify the default mode for newly created files.

chown C'!I, Ige the user owner of a file.


* chgrp C'i m ,_, the group owner of a file.









Some variants of UNIX, like AIX and HP-UX provide access control lists which

offer a further refinement to the standard UNIX file permissions capabilities. These

ACLs consist of three parts:


1. Attributes Specifies any special attributes like SETUID and SETGID.

2. Base permissions These correspond exactly to the UNIX file modes and
specify access rights for owner, group and others.

3. Extended permissions These are access information specified by user and
group name.

ACLs that specify a username and group are useful for accounting purposes. They

are also useful if you add a user on a temporary basis [33].

UNIX was the first 1i ii network operating system. It provides various

services like NIS (Network Information Services) and NFS (Network File System)

that help in administering a network. Using NIS, users can log on to any machine

on the network that belongs to the same NIS Domain. In a network with twenty

machines, the administrator has to add the new user on just one machine and that

user can log on to any one of these twenty machines. In order to provide a uniform

directory structure when a user logs in, administrators mount file systems over the

network. Usually, the user's home directories are mounted using NFS. This way the

user's files are available to him/her on any machine in the network. The advantage

with this arrangement is that controlling file permissions is the same as described

earlier.

Users authenticate themselves to the system by providing a user name and

password. It is very important for users to protect their passwords because if the

password is compromised, then all logins may be compromised [32]. Passwords

and file permissions are two basic v--,i- of preventing security problems in UNIX.

Passwords prevent bad guys from getting on the system in the first place and

proper file permissions prevent normal users from doing things they are not









supposed to [33]. There are only three access types and users cannot define their

own access types. Moreover, the owner of a file has full rights to do anything with

the file. In many organizations, the files are not 'I.--i: ,1" by the users but by the

organization itself.

3.4 Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) [34, 35, 36, 37, 38] is a model that is

gaining popularity. The principal motivations behind RBAC are the ability to

articulate and to enforce enterprise-specific security policies and to streamline the

typically burdensome process of security management.

In many organizations, the end users do not i.--v the information for which

they are allowed access. The corporation is the actual "c.--v i of system objects

as well as the programs that process it and control is often based on employee

functions rather than data ownership.

In RBAC, users do not have discretionary access to enterprise objects. Instead,

access permissions are associated with roles and users are associated with roles. A

role based access control policy bases access control decisions on the roles a user is

allowed to take on within an organization. The determination of role membership

and the allocation of transactions to a role is in compliance with organization-

specific protection guidelines derived from existing laws, ethics, regulations, or

generally accepted practices. With RBAC, users are not granted permission to

perform operations on an individual basis, but operations are associated with

roles. This has the advantage of simplifying the understanding and management of

privileges.

System administrators control access at a level of abstraction that is natural to

the way enterprises typically conduct business. RBAC addresses security primarily

for application-level systems, as opposed to general purpose operating systems.









RBAC enforces the following rules on role authorization, role allocation, and

operation execution. RBAC constraints are used to express separation of duty.


1. Role hierarchy If a subject is authorized to access a role and that role
contains another role, then the subject is also allowed to access the contained
role.

2. Static separation of duty A user is authorized as a member of a role only if
that role is not mutually exclusive with any of the other roles for which the
user already possesses membership.

3. Cardinality The capacity of a role cannot be exceeded by the addition of
another role member.

4. Role authorization A subject can never have an active role that is not
authorized for that subject.

5. Role execution A subject can execute an operation only if the subject is
acting within an active role.

6. Dynamic separation of duty A subject can become active in a new role only if
the proposed role is not mutually exclusive with any of the roles in which the
subject is currently active.

7. Operation authorization A subject can execute an operation only if the
operation is authorized for the role in which the subject is currently active.

8. Object access authorization A subject can access an object only if the role is
part of the subject's current active role set, the role is allowed to perform the
operation and the operation to access the object is authorized.

3.5 Distributed Compartment Model

The Distributed Compartment Model [39, 3] was proposed by Steven Green-

wald as a solution to management of system resources and access control in a

distributed computing environment. The model consists of two parts, (i) Dis-

tributed Handles, a means for user identification and access control and (ii)

Distributed Compartments, a method for allowing users to manage resources within

a distributed system across computer system boundaries with a measure of inde-

pendence from any system administrations [39]. The distributed handles eliminate









groupware application userlDs as a means of identification and access control.

A user joining a groupware session is queried for a handle that is unique to that

application and is then verified by a groupware security manager.

Under this method, an individual user would first gain access to a particular

computer system in the distributed system by having a valid user ID and password.

The user would then need a valid distributed handle and would then need to be

validated by the groupware's access control security in order to be allowed access to

the application.

The major advantage of this approach is that security dependencies are re-

duced. Moreover, the handles can be more descriptive than user IDs, for example

"Third programmer" instead of '. 0". Multiple handles can be permitted for the

same user and many users can share the same handle. Distributed compartment

(also called discom) is the designated platform for access control and administra-

tion of distributed handles.

A discom is a logical group of objects that is conceptually similar to a stan-

dard hierarchical directory structure but does not necessarily reside in a single

computer. The users of discoms gain access via distributed handles. A root discom

is called an empire discom. Each discom must have at least one subject called

governor. Governors have the maximum privileges for the discom they govern.

There are 24 basic operations called initial privileges. They include operations

that create, destroy, or modify objects, create, delete, merge, split, or modify child

discoms and empire, create or rescind privilege, create or remove governorships,

subjects or resources, etc. This combination of subjects, objects and privileges,

makes it possible to create a system similar to an access control matrix.

The Distributed Compartment Model has a set of axioms and properties some

of which are:









Divine Right Axiom A subject can create an empire discom only if given that
privilege by the administrators.

Creator Property The creator of a discom automatically becomes a governor
of that discom.

Government Property The governor of a discom may grant and revoke
privileges to non-governor subjects of that discom.

Nova property A non-governor subject may access a descendant discom only
if made a member of that discom by a governor of an ancestor discom.

Cordon Property Discoms may never intersect with other discoms.

Demesne Property The governor of a discom alr--,i- has unrestricted access to
descendant discoms.

Ceiling Property A subject may not access an ancestor discom without being
a subject of that discom.

A distributed compartment is actually a groupware application, with access to the

discoms determined by distributed handles. Management of discoms is not done by

the local system administrators but by the individual users who are governors of

empire discoms.

3.6 Access Control for Collaborative Environments

Based on the work by Greif [40] and Ellis [41], Bullock and Benford [42] have

identified four basic requirements for collaborative access models:


The mechanism must be simple.

The mechanism should be unobtrusive to users.

It should be easy to inspect and change access rights.

The effects of access controls should be understood, and the consequences of
any changes should be clear.

Haake et al. [43] "... found that end-users in order to conduct cooperative work

in shared workspace system have to be able to (1) create groups dynamically









without prior planning of a system administrator, (2) employ different forms of

group formation, and (3) control access rights to their workspaces." AT ii': current

systems lack sufficient support for these requirements.

Shen and Dewan [44] have extended the traditional access matrix model for

groupware with more than 50 basic access rights to handle the various operations

required for collaboration and inheritance based on right groupings. They also

support the notion of negative rights to allow explicit denial of rights.

Park and Hwang in [45] tailor the generic architecture for controlled Peer-

to-Peer (P2P) computing environments to support RBAC. For collaborative

enterprise in such an environment, they identify three different policies: enterprise,

community and peer. A community policy defines the community's User-Role

Assignment (URA), Permission-Role Assignment (PRA), constraints and role-

hierarchy. An enterprise policy defines the enterprise's URA, PRA, constraints,

role-hierarchy and role ontology (an equivalence relation between roles in different

communities [46]). Each peer defines its own peer policy including the peer's PRA

and constraints. The enterprise policy is enforced by a centralized mechanism that

applies to all communities in that enterprise, while a community policy is enforced

by a centralized mechanism within the community. These two mechanisms are

based on the brokered P2P model. If a conflict occurs between policies, enterprise

policies are superior to community policies, which are superior to peer policies

unless specific policy priority is defined.

Jaeger and Prakash [47] define a discretionary access control (DAC) model

for specifying the access rights available to a mobile agent which enables the

reader and writer in a mobile agent computation to flexibly control access to

system objects. They also specify the requirements of RBAC models necessary to

implement the DAC model. In this type of RBAC model, system administrators

define roles for users (as in regular RBAC) but can also define a model that will









enable users to limit the access rights of their own processes. First, system admins

specify the object types that can be used to specify operation access rights. Also,

system admins specify the users who are authorized to limit their own rights

dynamically.

3.7 Trust and Voting

While significant work has been done in the fields of Political Science, Psychol-

ogy, and, Ethics [48, 49], iii,-I of the work concerning trust in computer science

have been concentrated in the area of security ... mainly in the form of formal

logics to analyze cryptographic protocols for design flaws and correctness." [50].

One of the most popular definitions of trust is given by Deutsch [51].


(a) an individual is confronted with an ambiguous path, a path that
can lead to an event perceived to be beneficial or to an event perceived
to be harmful; (b) he perceives that the occurrence of these events
is contingent on the behavior of another person; and (c) he perceives
the strength of a harmful event to be greater than the strength of a
beneficial event. If he chooses to take an ambiguous path with such
properties, he makes a trusting choice; else he makes a distrustful
choice.

Gambetta [52] has defined trust as a particular level of the subjective probability

with which an agent assesses that another agent or group of agents will perform

a particular action, both before he can monitor such action (or independently

of his capacity ever to be able to monitor it) and in a context in which it affects

his own action." This definition has been widely accepted by computer scientists

Gambetta introduced the concept of using values for trust and also defended the

existence of competition among cooperating agents. Trust is closely related to

reputation [53]. Abdul-Rahman and Halies [50] define reputation as an expectation

about an individual's behavior based on information about or observations of

its past behavior. In online communities, where an individual may have very

less information to determine the trustworthiness of others, their reputation









information is typically used to determine the extent to which they can be trusted.

An individual who is more reputed is generally considered to be more trust worthy.

Reputation can be determined in several v-iv. For example, a person may either

rely on his direct experiences, or rely on the experiences of other people, or a

combination of both to determine the reputation of another person.

As mentioned earlier, work concerning trust in computer science has been

primarily focused on cryptography like in [54] and work in voting has be dominated

by electronic voting [55] where the emphasis is on authentication and guaranteeing

that the vote counted as voted. Marsh's model [56], as far as we know, is one of the

few attempts to formalize trust based on the real world social properties of trust.

3.8 Summary

The HRU model is a very powerful model in terms of expressive power.

However, it is very primitive in its construction and has no roles, object types or

other abstractions. Therefore the matrix can be very large (and sparse). It is not

easy to implement this model in a distributed system.

The TAM model takes a huge step forward with the addition of typing.

However, the set of types is static and there are no operations defined in the system

to change the type of an object or subject. As we will show in the later sections,

making it possible for the users to define their own types and change the types

allows us to implement many important and interesting system policies.

RBAC provides a means of naming and describing relationships between

individuals and rights. Some form of RBAC is used in commercial systems tod iv

and some attempts have been made to formalize the model (refer [36]). One of the

i, P"r areas in which the DCS model scores over RBAC is group decisions. Another

restriction is the absence of some mechanism that allows defining one-to-one

relationships between subjects and objects. For instance, consider the ownership

relation. Pure RBAC can handle the case where each object has only one owner,









however, if some objects in the system have a small subset of users as its ownerss,

it is impractical to define new roles such as owner of object 1 (we will need as

n: i in: such "owner 1,.!, as there are objects).

One n1i ri" disadvantage with the Discom model is that users will have to have

a separate handle for each application they use. This means that they will have

to remember not just their user ID and password but the handle and password for

each application. It would have been preferable to avoid such multiple "lc-i-

Since many users can share handles, this reduces accountability. The Discom model

practices a type of monarchy in which the governors have absolute power whereas

a democratic form of government will be more practical in the long run. The

Discom model is really concerned with resource management in hierarchical groups

distributed over multiple domains. The DCS model is concerned with authorization

issues and these two models can be used together, providing a secure, flexible

system.

All the above models require a system administrator to handle the changes in

the system. Incorporating group voting mechanisms allow the users to decide and

implement the group policies. This is one of the main features of the DCS model.

The Jaeger and Prakash model allows system administrators to specify some

DAC features and who can use them. The users with the privilege can control

access to their processes but this is still very limited DAC and does not allow

the groups to decide their own policies (they can do so only for those objects

the system admins allow). The RBAC scheme for P2P environments described

above relies extensively on server controlled decisions and does not support group

decisions. It does however support co-n-ninitv-1. v.l autonomy which allows policy

decision to be made off-line and changes are enforced by someone with admin-level

privileges.















CHAPTER 4
THE DCS-AC MODEL

4.1 Introduction

In this chapter, we will introduce and formally specify the Distributed Con-

ferencing Services Access Control (DCS-AC). We will also discuss the constraints

and rules that are imposed on any system that implements this model. Finally, we

will discuss some of the key features of the model and show the DCS-AC solution

to the software problem mentioned in section 1.2.

4.2 The DCS-AC Model

The access control matrix is often very big and sparse. Role-based Access

Control (RBAC) groups subjects into roles and objects into object 'i',,. thereby

shrinking the matrix. In these systems, each cell in the matrix correspond to the

set of rights the corresponding role (identified by the row) had with respect to the

object type (identified by the column). In the DCS-AC model, we are concerned

with two additional aspects, decision template and target.

The decision template is a pointer to some voting template (see Section 6.2.2)

which should be invoked in order to make a decision on the access request. We

expect most entries in the matrix to point to the Always-;I. template which simply

returns a ;/. without calling for a vote. Typically, requests that result in granting

a right to some role might require a vote but once granted, exercising that right

may not require one. It is up to the users to decide which requests require a vote

and which do not require one. Needless to -iv, any request that requires a vote

will take some time to be processed and so, the group policies should be designed

carefully.









The target field is a very powerful idea which helps us achieve fine-grained

access control (see Section 4.6.5). Instead of -,i-ing "role President can allow

subjects to bind to the role ExecutiveM. ni,,l by using a target field, we can

specify the right in finer detail by -,i-ing "role President can allow subjects of

role TrustedMember to bind to the role ExecutiveM. m,,, Here, the target is the

role TrustedMember since we are narrowing down the scope of this right to just

this role. Depending on the type of command being executed, the target can be a

role, object type or a right. In the case of rights for which the target field is not

applicable, it is null and the keyword i;i, specifies that the right can be exercised

on any target.

The distribution of rights in the system are can be viewed as an access matrix

(implemented as a five-field RDBMS table), A. The cell A[X, Y] contains a set

of (p, Z, dp) tuples where p is a right which role X has for objects of type Y with

respect to a target, Z and dp is a pointer to a decision template that must be

activated each time X makes a request to perform p on (Y, Z).

We achieve a great deal of flexibility by allowing the group to dynamically

change a 1 ii' r part of the system components. Unlike the TAM model, we allow

types (i.e., roles and object types) and type bindings (subject-role and object-type

bindings) to be added and deleted dynamically by the group according to the group

policy as represented by the matrix. Similarly, the set of rights and the available

decision templates can also be changed while the system is in operation. The only

static component of the model is the set of commands which are the same for all

instances of the model.

Each subject can bind to one or more roles but at any point of time, the

subject can be active in only one role. The user can temporarily change his/her

active role to another role to make a request that is not allowed for his/her current

role. One of the main reasons for this restriction is that the user has to be aware









of the increased responsibility while requesting access that requires membership to

a privileged role. Each object is bound to one object type. These bindings can be

changed by .in:one who has the right to do so. This is a ii, difference from the

TAM model in which the bindings are a part of the system definition and can only

be altered by an external administrator. In the DCS-AC model, the administrator

is considered to be a part of the system and is subject to the access restrictions

imposed by the matrix. An instance of DCS-AC has the following finite dynamic

sets:


a set of access rights denoted by R,

a set of decision templates denoted by D,

a set of object types denoted by T,

a set of roles denoted by TR(C T),

a set of objects denoted by OBJ, and

a set of subjects denoted by SUB.

The access control matrix is denoted by A. We have three mapping functions, fr

which maps each subject to a subset of TR (corresponding to the roles to which

the subject can bind), fo which maps each object to an element of T (its object

type)1 and f, which maps each active subject to his/her active role.


f, : SUB 2T


fo : OBJ T



1 If an object is allowed to be of more than one type, access control decisions are
difficult. Should a user have rights to access all object types of an object in order
to access the object? An alternative is to define an object type hierarchy, which
increases the complexity of the model.









Table 4-1: Example of DCS-AC Matrix Fragment

Role Object Type Target Right Template
1 Programmer Code null Read dyes
2 Programmer Code null Write dyes
3 Programmer Code Read GrantRight di


f, : SUB-TR

The state of a DCS system is the tuple (A, R, D, T, TR, OBJ, SUB, fr, fo) and as

noted earlier, the set of commands C (defined in section 4.4) is the only static

component of the model. A few simple examples of the matrix entries are given in

table 4.2. Here, Programmer is a role and Code is an object type. Read, and Write

are access types and dyes is a pointer to the Ala, .--;. template. The first three

entries allow subject who are actively in the role Programmer to read and write

objects of type Code. The third entry allows Programmers to grant Read access

to anyone if the decision template di returns yes. The decision template dl might

require the approval of the Project Leader and Dev Team Manager. GrantRight is

a special access right that corresponds to a primitive operation that adds an entry

to the matrix.

4.3 Operations

Lets us now look at the primitive operations that can be executed on a DCS-

AC system. These are operations that modify one or more components of the

system and are guaranteed to be atomic. We will formally define the operations

by specifying their effect on the system. Let (A, R, D, T, TR, OBJ, SUB, f,,

fo) denote the system before the operation and (A', R', D', T', TP, OBJ', SUB',

f fo) denote the system after the operation. Table 4.3 defines the primitive

operations in DCS-AC. Note that sets not mentioned in the definition of an

operation are unchanged by that operation. There is one command for every

operation but we might want to have commands with two or three operations

especially if we want roles and object types to have pedigree (see section 7.1).











Table 4-2: Specification of DCS-AC Operations


Operation Precondition Postcondition


grantright(r, ot, p, t, dp)



revokeright(r, ot, p, t)



createrole(r)


deleterole(r)


createot(ot)


deleteot(ot)

addobject(o, ot)


delobject(o)

addsubject(s, r)


r E TR,t TUR,
tE T, pE R, dp E DT,
Vdpl e DT,
(P, t, dp1) V A [r, ot]
r c TR,t TUR
ot T
pER

r TRp


- s, f(s) {r}


ot V T


-3o, fo(o)

o OBJ
ot T



re Tp


A[ri, oti]



A[ri, otl]


r,ot] A (pi / p) A (ti t)}

[ri, oti] A[ri, otl]


'[ri, ot] = A[ri, oti]
(s) {r}


(pi,ti,dpi) c A[
TR = TR U {r}
V (ri,oti) E TR x T,A'
V otl e T, A'[r, otl] 0
TR = TR {r}
V (ri, oti) Ti xT, A
V sl E SUB, f((s) f,
T' TU {ot}


V(r, oti) Tp X T', A'[ri, oti] A[ri, oti]
Vrl E TR, A'[ri, ot] 0=
T' T' {ot
V(r, ot) E TR x T', A'[r, ot] = A[r, ot]
OBJ' OBJ U {o}
Vo1 e OBJ, f(ol) fo(ol)
f'(o) = ot
OBJ' = OBJ {o}
Vo1 E OBJ', f'(ol) = fo(ol)
SUB' = SUB U {s}
V sl E SUB, f/(si) f,(si)
f;(s)= {r}


V (ri, oti) TR XT,
((r, oti) / (r, ot)) -A'[ri, otl]
A'[r, ot] A[r, ot] U {(p, t, dp)}

V (ri, ot) E TR x T,
((ri, oti) (r, ot)) A'[ri, otl]
A'[r,ot]= {(p1,ti, dp1) :
















Table 4.2: Continued


Operation Precondition Postcondition
delsubject(s) SUB' = SUB {s}
Vs1 E SUB', f (si) f,(si)
addaccess(p) R' = RU {p}
delaccess(p) R' R- {p}
V (r, ot) E TR x T,
A'[r, ot] = {(p, t, dp) : (pi, t, dp) E A[r, ot] A (pi / p)}
,,l,;,,.1 1,].,/1,,,(s, r) s c SUB Vs E SUB -{s}, f(si) f,(si)
r e TR f(s) f(s)U {r}
delrolebinding(s, r) s E SUB Vsi E SUB {s}, f,(si) = ,(si)
r TR f'(s) = f,(s) {r}
fr(s) {r}
lilj'. .r,t, ot, p,dp) r TR,tETUR V (ri, otl)E T x T,
ot ET ((ri,oti) / (r,ot)) --A'[ri, otI] A[ri, ot]
p R A'[r, ot] {(p, ti, dpl) : (pl, ti, dpl) E A[r, ot] A pi /pAt / t}
dpC DT U {p,t,dp}
, I1,,'I...(o,ot) o OBJ Vo1 E OBJ,ol / o f(ol) fo(ol)
ot c T f (o) = ot









4.4 Commands in DCS-AC Model

The access control matrix can only be modified through the set of commands

which is the only static component in the DCS-AC model. Unlike the HRU and

other models, the set of commands does not vary from system to system. There

is one command for each primitive operation; it checks if the subject's role has

the right to perform the operation and if so, then it performs the operation. A

command consists of two parts: a conditional part that checks if the role is allowed

to make the request and an execution part that executes one operation. All objects

belonging to the access control model (like A, fo, DT, T, Tp etc.) are of the object

type F. Given below is the list of commands in DCS-AC. In all these commands, r

is the role of the subject executing the command.


command CreateRole(r E TR, new V TR)
if ((CREATEROLE,null,dp) A[r,F]) for some dp E DT and dp
returns true then
createrole(rnew)

command DeleteRole(r G TR, r1 E TR)
if -3s, f(s) = {ri} and ((DELETEROLE,null, dp) e A[r,ri]) for some
dp G DT and dp returns true then
deleterole(ri)

command GrantRight (r E TR, rl c TR, t E TU R, ot E T, p c R, dpl E DT)
if -3dp2,(p,,dp2) G A[ri,ot] and ((GRANTRIGHT,p, dp) c A[r,ot]) for
some dp G DT and dp returns true then
grantright(ri, ot, p, t, dpi)

command RevokeRight(r c TR, rl E TR, t TU R, ot E T, p e R)
if ((REVOKERIGHT,p, dp) E A[r,ot]) for some dp E DT and dp
returns true then
revokeright(ri, t, ot, p)

command CreateOT(r E TR, ot V T)
if ((CREATEOT,null, dp) A[r,F]) for some dp E DT and dp returns
true then
createot(ot)









* command DeleteOT(r E T, ot E T)
if -io,fo(o) = ot and ((DELETEOT,null, dp) E A[r,ot]) for some
dp E DT and dp returns true then
deleteot(ot)

* command AddSubject (r E TR, Snew SUB, initial E TR)
if ((ADDSUBJECT,rinitial, dp) E A[r,F]) for some dp E DT and dp
returns true then
addsubject(s, initial)


* command DelSubject(r E TR, s SUB)
if ((DELSUBJECT,null, dp) E A[r,F])
returns true then
delsubject(si)

* command AddObject(r E TR, o OBJ,ot
if ((ADDOBJECT,null, dp) E A[r,ot])
returns true then
,,7,, i., /(o, ot)

* command Del0bject(r TR, o e OBJ)
if ((DELOBJECT,null, dp) E A[r,ot])
returns true then
delobject(o)


for some dp G DT and dp



E T)
for some dp G DT and dp




for some dp G DT and dp


* command AddRoleBinding(r E TR, s c S, ri c TR)
if ((ADDROLEBINDING,rs, dp) E A[r,rl]) for some dp E DT and
rs E f(s) and dp returns true then
addrolebinding(s, ri)

* command DelRoleBinding(r E TR, s G S, ri G TR)
if fr(s) / {ri} and ((DELROLEBINDING,null, dp) e A[r,ri]) for some
dp G DT and dp returns true then
delrolebinding(s, ri)

* command ChangeOT(r E TR, o E OBJ, otnw E T)
if ((CHANGEOT,fo(o), dp) E A[r,ote,]) for some dp E DT and dp
returns true then
changeot(o, otnew)

* command AddAccess(r G TR, p R)
if ((ADDACCESS,null, dp) E A[r,F]) for some dp E DT and dp
returns true then
addaccess(p)









command DelACCESS (r TR, p R)
if ((DELACCESS,p, dp) E A[r,F]) for some dp E DT and dp returns
true then
delaccess(p)

command ChangeDP (r E TR, rl E T t TU R, ot T, p E R, dpnew E DT)
if 3dpli,(p,t,dpi) E A[ri,ot] and ((CHANGEDP,p, dp) A[r,ot]) for some
dp E DT and dp returns true then
changedp(ri, t, ot, p, dpnew)

It is obvious that all the commands can be executed in constant time (as-

suming an that looking up the access matrix and other DCS-AC components can

be done in constant time). Moreover, the roles and object types created by the

CreateRole and CreateOT commands have no pedigree, i.e., the creator of the role

or object type has no special rights over that role or object type. We also allow the

object type, access right and the target to be replaced by the keyword ANY. For

example, if (ANY, ANY, dp) E A[Secretary, ANY] where dp is a decision template

that calls for a simple i I i i, ily of all subjects who can bind to the role Senator,

then a Secretary can make any change to the system if approved by a iI i ii i ly

of the senators. Since the roles and object types have no pedigree, there has to

be a group policy for granting rights to these roles and object types (typically,

(GRANTRIGHT, ANY, someDP) E A[SomeRole, A111]).

4.4.1 Constraints

There are a few constraints that have to be enforced on the system, some of

which have been mentioned earlier.


Active Role At no point of time can a subject be active in more than one
role.

Role Authorization A subject can only be active in roles he/she is authorized
to be in.

Operation Authorization A subject can perform only those operations that
his/her active role is authorized to do.









Object Access Authorization A subject can only access those objects his/her
active role is authorized to do.

Amendment Rule There should alv--, be a rule that allows the group to
modify any component of the system.

Delete Restriction A role or object type cannot be deleted if it results in a
violation of the rules and constraints.

Graceful Deletion If an active subject is deleted from the system, the deleted
subject should lose all right immediately.

Decision Template Overwrite Rule A GrantRight command should not be
allowed to change the decision template of an already granted right.

The Active Role constraint is enforced to simplify the access checking process. The

Role Authorization, Operation Authorization, and Object Access Authorization

are RBAC enforced constraints. Amendment Rule is like an emergency override

to allow the group to recover from unusable states. Typically, this is enforced by

a matrix entry that allows a particular role to change anything if some template

returns a yes. For example, the Chairman can change any rule if all the F2I. ,1/ I

and the College Dean agree.

The Delete Restriction is imposed on deletion of roles and object types. If

there is a subject that can bind to only one role, then deleting that role means that

the subject cannot bind to any role. This is an inconsistent state and should be

avoided. This subject should be deleted or allowed to bind to another role before

deleting this role. Furthermore, if there is a subject currently active in a particular

role, then that role cannot be deleted. Similarly, if there is at least one object that

belong to a particular type, that type cannot be deleted.

The G, r, ful Deletion rule is for deleting subjects who are currently active.

They should be immediately 1. 1.-.-- 1 out of the system with suitable notification

messages. The Decision Template Overwrite Rule prevents some subject from

changing the decision template for an entry in the matrix by using the GrantRight









command. This is enforced by ensuring that no GrantRight command grants an

already existing command. The decision template pointers for an entry can only be

changed by the Ci', ,, I)P command.

4.4.2 Expressive Power

It is well known that the HRU model has very good expressive power but is

very weak in terms of provable safety. It can be seen that the DCS-AC model also

has very good expressive power. Any HRU protection state can be converted to the

DCS-AC model.

Mapping from HRU to DCS-AC

Consider a protection system (R, C) and a state (S, O, P). Let us define a new

role for each user and allow only that user to bind to that role and call the set of

these roles TR. Similarly, define a new object type for each object and call this set

T. We define DT = {dp} where dp is a pointer to a decision template that alv--xi

return i, Let the new DCS-AC instance be (R, DT, T, TR, O, S, fo, fr, A).


V oi G 0 add a new object type oti to T and let fo(oi) = oti

V Si E S add a new role ri to TR and let fr(si) = {ri}.

A[r, ot] = {(p, null, dp): p G P[si, oi}

Now we have an instance of DCS-AC model defined by (R, DT, T, TR, O, S, fo,

fr, A). Although the system state in the two models are equivalent, the systems

themselves are not equivalent because we have not mapped the commands of the

HRU model to something equivalent in the DCS-AC model.

Mapping from DCS-AC to HRU

Similarly, we can do a mapping from DCS-AC to HRU. Here again, the two

systems will not be equivalent because of dynamic typing and decision pointers.

Consider an instance of the DCS-AC model (R, DT, T, TR, OBJ, SUB, f,, fo, A).









We can convert this into a HRU system (R', C) with the configuration (S, O, P) as

follows:


1. R' = R Rm where Rm is the set of all matrix manipulation operations
not supported by HRU.

2. S = SUB and 0 = OBJ

3. V(s,o) SUB x OBJ
(a) Vr E f,(s), P[s, o] = {p : (p, null, dp) E A[r, fo(o)] A p f Rm}

4. Add commands to perform each of the six operations if the subject has the
right similar to the one specified in section 4.4.

Note that the resulting HRU instance is a mono-operational one and hence the

safety of this is decidable in NP time. Here, we drop all typing information,

decision pointers and operations not allowed by HRU.

4.5 Comparison with existing models

One 1i ii Pr difference between the DCS-AC model and the other models is the

fact that the AC'\ I itself is an object and there is a right corresponding to each of

the above mentioned operations. If a user wants to perform a matrix modifying

operation, then his/her role should have the right to do so. It must be noted that

in TAM, R, T, TR and t are all part of the system definition and cannot be altered

by anyone within the system, whereas these are a part of the DCS-AC model

instance and can be modified by anyone who has the right to do so. TAM does not

have the notion of decision pointers either. TAM allows any number of parameters

in its commands but the DCS-AC allows at most five.
+ Dynamic Typing
Strong Tping + Decision Pointers
Arbitrary Commands

Figure 4-1: Comparison of HRU, TAM and DCS-AC models


The TAM model added the notion of strong typing to the HRU model.

The DCS-AC model has dynamic typing, static set of commands (as opposed to









arbitrary commands) and most important of all, decision template pointers that

allows the members of the group to decide on access right issues. Another i i" r

difference is the dynamic set of access rights. As mentioned earlier, the term role

as used in the DCS-AC model is different from what it means in RBAC. Here are

some differences between the two:


Role Hierarchy There is no role hierarchy in the current implementation of
the DCS-AC model. Subsection 7.3 talks about how the DCS-AC model can
be extended to implement role hierarchy.

Static Separation of Duty The DCS-AC model does not support static sep-
aration of duty. However, it is possible to implement dynamic separation of
duty using function calls. All separation of duty policies can be implemented
as dynamic which provides greater flexibility to the users.

Decision Pointers The use of decision pointers is the new paradigm introduced
in this model. As mentioned earlier, this addition is very useful in specifying
various system policies.

4.6 Features of DCS-AC Model

The access control matrix and the functions mapping various sets are stored

as tables in a backed database which is replicated across all sites. All updates

and deletions are propagated to other sites by a separate Database Services module

(DBS) which guarantees processor consistency for updates, i.e., updates originating

from the same processor will be committed at all sites in the same order. This

is achieved by assigning an owner site for each tuple in the table. When a new

tuple is to be added, the site the request originated is the owner. Modifications

to a particular tuple are forwarded to its owner which then multicasts to other

sites. The decision templates are maintained by the Decision Support Services

module (DSS) which stores the vote participants, percentage of votes required for

success and other information about the template. When the access control module

initiates a decision, the participants are notified and the votes are collected. Once

a decision is reached, the DSS passes it to the access control module which takes









further action as required. Note that in many cases, the decision pointer may point

to a template that alv--,v- returns a ; -

4.6.1 Decision Templates

Decision templates are one of the most interesting features of the DCS-AC

model. The use of group voting mechanisms allow the users to self-administer their

groups. It is quite clear that the safety of the system will depend very heavily

on the decision pointer. It will be very interesting to study the various types of

collusion attacks possible based on a given set of decision pointers. A decision

template contains the following information: (i) A list of voters along with the

weight of each entity's (role/subject) vote, (ii) number of voters for quorum, (iii)

start and end times, (iv) percentage of voter who have to agree for the vote to pass,

(v) default policies if quorum is not reached, and (iv) other bookkeeping details like

who should be notified of the result etc. The template also specifies what kind of

vote to start (ranking, simple i1: ii, ,iily, multiple rounds, etc.). It is expected that

most access requests will invoke a simple decision template that ahv--, returns .;/,

and only a few access requests (like granting a right to a role or any thing deemed

important by the group) will require a vote.

If we allow the decision pointers to be pointers to a voting process or a

function call that returns a decision based on the state of the system, we can

implement interesting policies like the separation of duty. If the global policy

states that any user who has access to objects of type 01 should not have access

to objects of type 02, then the decision pointer will execute a function that allows

the access only if the cell corresponding to [R, Oi] is null for every R in the set of

all roles the subject can bind to. However, the use of function pointers might make

the access right leakage problem undecidable and is currently not a part of the

DCS-AC model.









4.6.2 Dynamic Type Binding

The binding between objects/subjects and their types is static in TAM (HRU

does not have types). There are many scenarios in which this binding has to be

changed. By allowing the bindings to change, we can also model process work

flows. For example, if the group policy states that the review team should not

be able to access the code until it passes the testing phase. We can define three

different object types, working code, ready-for-test and ready-for-review. When the

code is ready for'. -1 ii:- the project leader or the developer can change the object

type of the files to ready-for-test. Now the testers can do their job. An additional

advantage in doing things this way is that the programmers cannot modify the files

that are being tested (if they do not have that access for objects of type ready-for-

test. If the code fails testing, the PL can change its type back to working code else,

he/she can change it to ready-for-review.

4.6.3 Dynamic set of Access Rights

As mentioned earlier, one of the differences between the DCS-AC model and

the other models is the fact that the access rights are not a part of the system

definition. When a new application is added to a system with a static set of access

rights, fine-grained access control has to be managed by the application itself. In

the DCS-AC model, when a new application is added, we can define new access

types to the system and make access control decisions at the system level. For

example, if a new audio-video application is added, we can define new access types

like j/'l;, audio file, recompress the file, cut and crop files, etc. Now, based on the

roles (like producer, sound engineer, etc.) it is straightforward to define access

control policies like a producer can pl il an audio file but cannot modify it, a

sound engineer can pl ii-, recompress, cut and crop an audio file. We can also define

special relations so that only the producers and sound engineers working with a









particular artist can access the audio files recorded by that artist. As we can see,

the realm of possibilities is very large.

4.6.4 Dynamic set of Object Types

In most real world scenarios, it is impossible to keep the set of object types a

constant. We cannot foresee all possible object types during system initiation and

although the need may not be very frequent, it is very likely that any system will

need new object types at some point of time. When a the audio-video application

mentioned in the previous section is installed, we have to create a new object

type (called audio file). It is quite possible to just use the type generic file and

individually specify the access rights for each audio file. This is how it will have to

be done in TAM. However, the main advantage of using types is the reduction in

the size of the AC' I and hence, specifying the rights for each and every audio file is

counter-productive in terms of AC\ I size. Thus it is more logical to allow the set of

object types to change with the needs of the users.

4.6.5 Fine Grain Access Control

As can be seen from the commands in DCS-AC (Section 4.4), the use of

the /,1,., I field allows us to define very fine grained access control policies. For

example, we can specify that role r has the right to grant read access to objects of

type ot ((GRANTRIGHT, read, dp) E A[r, ot]) and we can similarly specify revoke

rights for specific accesses. Another instance of fine grained access control is the

Cliq.I'OT command. If a manager can declassify a TopSecret document to Secret

but too only with the approval of the CEO, then (CHANGEOT, Secret, dpi) E

A[M n,,.,I. r, TopSecret] where dpl is a decision template that has only one voter,

the CEO. This level of granularity is not available in most access control models in

use todv.









4.7 DCS-AC Model Solution for Software Project Example

Here is a solution to the software project example mentioned in section ref-

motivation using the DCS-AC model. Let the set of roles be TR {PL, Architect,

Prog, Tester}. When the project (lets call it X) is started the following object

types are created: XDesignDoc, XCode, XWorkingCode, XTestedCode and XShip-

Code. The following roles are also created: XPL, XArchitect, XProg and XTester.

We now add the entries specified in table 4-3 to the access control matrix, A.

Here, dpi is a decision pointer that albv-i- returns P. dp2 requires a vote of

all subjects who can bind to XProg and dps requires a vote of all subjects who can

bind to PL. Entries 1,2 and 3 allow the X PL to decide who works on a project

but ensures that policy 6 (PL cannot change the role of an employee) is enforced.

This is a simplistic view of things and it is very easy to envision a system where

compile and execute are valid accesses which are used by a DCS-aware development

environment.

Thus class libraries example is solved by using the DCS-AC model. Similar

solutions are suitable for collaborative contract editing and many other distributed

collaborative applications. This example also illustrates how the DCS-AC model

can be used to model process work flow.











Table 4-3: DCS-AC Solution for Software Project Example


No. Entry Explanation


(ADDROLEBINDING, Architect, dpi) E A[XPL, XArchitect]

(ADDROLEBINDING, Prog, dpi) E A[XPL, XProg]

(ADDROLEBINDING, Tester, dpi) E A[XPL, XTester]

(ADDOBJECT, null, dpi) E A[XArchitect, XDesignDoc]

(read, null, dpi) E A[XArchitect, XDesignDoc]
(read, null, dpi) E A[XPL, XDesignDoc]
(write, null, dpi) E A[XArchitect, XDesignDoc]
(read, null, dpi) E A[XProg, XDesignDoc]
(ADDOBJECT, null, dpi) E A[XProg, XCode]
(read, null, dpi) E A[XProg, XCode]
(read, null, dpi) E A[XPL, XCode]
(write, null, dpi) E A[XProg, XCode]
(CHANGEOT, XCode, dp2) A[XProg, XWorkingCode]

(read, null, dpi) E A[XTester, XWorkingCode]
(CHANGEOT, XWorkingCode, dpi) E A[XTester, XCode]

(CHANGEOT, XWorkingCode, dpi) E A[XTester, XTestedCode]

(read, null, dpi) E A[PL, XTestedCode]

(CHANGEOT, XTestedCode, dp3) E A[XPL, XShipCode]


The PL can assign architects
to the project
PL can add programmers to
the project
PL can add testers to
the project
Architects can create design
documentation
Architects can read the docs
The PL can read the docs
Architects can write to docs
Programmers can read the docs
Progs can create code files
Progs can read the code files
PL can read the code files
Progs can write to the code files
Progs take a vote to submit
code for testing
Testers can read working code
Testers can return code
to programmers
Testers can mark code ready
for review
All PLs in the company can
look at tested code.
PL can ship code if
review team agrees









4.8 Summary

In this chapter, we defined and discussed the DCS-AC model. One of the main

features of this model is the ability of the subjects to vote on important (as defined

by the group) decisions. All subjects belong to one or more roles and all objects

belong to an object-type. The access matrix entry for a particular role and object

type contains a set of ordered pairs corresponding to the rights the role has over

the object type and the decision template that is executed when a subject of that

role tries to use that particular right over the object type. The decision template

might point to the Al, i. ;--.;. template (which ah--iv returns .;. -) or any other

template defined by the group. There are sixteen primitive operations and sixteen

commands (each of which correspond to one of the operations). These are the

only static components of the model. The group can define and modify all other

components like roles, object types, etc. dynamically. There are a few constraints

that have to be enforced when implementing this model. The commands in DCS-

AC are designed in such a way so as to allow fine-grained access control, i.e., we

can specify rules like Role X can allow a subject of role Y to bind to the role Z

instead of just a more general rule like Role X can allow a subject to bind to role Z.

It should be remembered that while all these features are really powerful, care

must be taken to avoid getting into a state that makes the system difficult to use.

The Amendment Rule constraint enables the group to recover from any such bad

states. In the next chapter, we will prove that the model is provably safe.















CHAPTER 5
SAFETY ANALYSIS

5.1 Introduction

The presence of decision pointers makes the safety analysis of the DCS-AC

model very tricky. Consider a restricted version of DCS-AC where there is only

one decision pointer in the system, dp, and that pointer ah--,i- returns true. This

is a valid restriction because, if trusted deciders control a decision, they will vote

no, so we can remove these entries from the matrix and any decision controlled by

untrusted deciders will, in the worst case, ah--,i-b result in p. We will first analyze

the safety of such a restricted model and in the next chapter, we will discuss the

safety of the full model.

5.2 Definitions

Let us now look at some definitions that will help us understand the safety

properties of the DCS-AC model.

Definition The state, S, of a DCS-AC system is a snapshot of the system at a

given time. It consists of the access control matrix A, the role binding function fr,

the object type binding function fo, and the following sets:


set of rights R,

set of subjects SUB,

set of objects OBJ,

set of object types T,

set of roles TR (TR C T), and

set of decision templates DT.









Definition For a given state S, object type ot, and right p,


s,p,ot {s : s E SUB A 3 r E f,(s),t E (TURU0) such that (p,t,dp) E A[r,ot]}

In other words, 4s,p,ot is the set of all subjects who have the right p for objects of

type ot in S. We can get the set 4s,p,ot in O(ISUBI TRI IRI) time as follows:

function getPhi (S, p, ot)


1. result = 0

2. for all s SUB
(a) for all r fr(s)
i. for all (p',t',dp) E A[r,ot]
A. if p' p then
result = result U {s}
Process next s

3. return result

Definition Given two states, S and S', and a command, a, we S -, S' if the

command a can be executed on S and S' is the result of performing the operation

in a on S (i.e., applying a on S results in S').

Definition Given two states S and S', and a sequence of commands a (containing

k commands, al, a2, ..., ak), we il


S ,Sif k 0 S S'k 1 S-, S'
S S' if
k > 1 = S -1 Si A Si ,-' S', where a' = a2, a3,..., ak

Definition For a given DCS-AC state S, object o, and right p, we i- that a

sequence of commands a results in a leaking state if and only if


S -- S' = 4)S,,p,f(o) 4S,p,fo() / 0


Let us now define the access right leak problem in the context of the DCS-AC

model.









Definition For a given DCS-AC state S, object o, and right p, the access right

leak problem is a decision problem is the question, does there exist a sequence of

commands on S that results in a leaking state.

5.3 Attributes of a State

In order to help us keep track of the commands that have been executed and

those that can be executed, we identify certain attributes which are dependent on

the current state of the system. Each of these attributes can be active (i.e., the

command has been executed), enabled (the command has not been executed but

there is some role in the current state that can execute the command), or inactive

(the command has not been executed nor can any role execute the command in the

current state).

For any state St (reached by executing 0 or more commands on the starting

state SO), the following attributes are valid:


1. HasRightr,0ot,p',t This attribute tracks the GrantRight commands and
is said to be active for St if (p', t, dp) E A(r', ot') for some dp E DT.
If the attribute is not active, we -i,- that this attribute is enabled if
3 r, dp' such that (GRANTRIGHT, dp') e A(r, ot')

2. CanB.:,.1,r,/ This attribute tracks subject-role bindings and is said to be
active for St if r' E fr(s'). If the attribute is not active we -i- that this
attribute is enabled if 3 r, dp' such that (ADDROLEBINDING, dp') E
A(r, r')

For a given starting state SO and a descendant state St (reached by executing 1 or

more commands on the starting state So, i.e., 3o such that l|l > 1 A So St),

we identify the following attributes that are valid for St and all states that result in

executing a sequence of commands on St:


1. NewRole This attribute is said to be active for St if one of the commands
we have executed on SO is a CreateRole command. It cannot be active for
So. If the attribute is not active, we -i,- that this attribute is enabled if
3 r, d' such that (CREATEROLE, d') E A(r, F)









2. NewOT This attribute is said to be active for St if one of the commands we
have executed on So is a CreateOT command. It cannot be active for the
initial state S. If the attribute is not active, we -;v that this attribute is
enabled if 3 r, d' such that (CREATEOT, d') E A(r, F)

3. NewSubject,, This attribute is said to be active for a state St if one of the
commands executed is a AddSubject command with the initial role r'. These
attributes cannot be active for S. If the attribute is not active we -v- that
this attribute is enabled if 3 r, dp' such that (ADDSUBJECT, dp') E A(r, r')

These attributes are activated by executing the corresponding commands.

Active(S') is the set of attributes that are active in a state S' and Enabled(S')

is the set of attributes that are enabled in S\.

5.4 Proofs

Let us now look at a few lemmas and theorems that will lead to a polynomial

time solution to the ARL problem for at DCS-AC system without voting.

Definition We -i- that two states S' and Sj (with the same starting state SO) are

equivalent in terms of access right leakage if:


S' is a leaking state #z S is a leaking state



Axiom 1 In a DCS-AC system with an initial state S, two sequences of com-

mands, al and a2, result in equivalent states if the active attributes of the two

r, -.il:,.,i state are the same.


(S ->, S1) A (S -, S2) A (Active(S1) = Active(S2)) 1 S1 S2

Lemma 2 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


* a' results in a '.., /':ui state and









a does not contain iwi;, command that revokes a right or deletes a subject,
object, role, object type or access.

Proof Let a = al, a2,..., oak and let ai be the first revocation or deletion command.

Let j (1 < j < k) be the smallest number such that the sequence al

ac, ..., aj results in a leaking state S'. Clearly, j / i since ai is a revocation or

deletion command.

Case 1: j < i

If j < i, then the sequence a1 results in a leaking state and does not contain

any revocation or deletion commands (since ai is the first such command and

j < i) and hence a1 is the sequence we are looking for.

Case 2: j > i

Consider the sequence a2 = al, ..., ai- i+, ..., aj. We know that the

commands ai+l, ..., aj can be executed even if we had executed ai (which removes

something from S). Moreover, all commands check for the presence of some right

and not for the absence. Therefore, the commands in a2 can still be executed and

hence, this sequence will also result in a leaking state.

Repeating the above step for all revocation and deletion commands in a, we

get a', a sequence which does not contain any revocation or deletion command and

results in a leaking state if a results in a leaking state. I

Lemma 3 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a '. i.:,'i state and

a' does not contain i,:1, AddObject, AddAccess, or C('!h igeDP commands.

Proof Let a = al, a2,..., a, and let ai be the command that adds a new object

ol. We construct a1 by removing ai and all other commands in a that change









the object type of ol. Since Clhi.,,. OT is the only command that depends on the

existence of ol, all the other commands can still be executed.

Since the presence or absence of ol does not affect the right leak for o (as per

the definition of right leak problem above), if a results in a leaking state, then a1

also results in a leaking state.

Repeating the above steps for all AddObject commands, we get a sequence a2

which does not contain any AddObject commands and results in a leaking state if a

results in a leaking state.

Using similar arguments, we can remove all AddAccess commands from

a2. Moreover, since there is only one decision pointer in the system, C'lI'h,, 1)P

commands can ignored.

So we now have a sequence a' which does not contain any AddObject, AddAc-

cess or Clh,i,, I)P commands and results in a leaking state if a results in a leaking

state. I

Corollary 4 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I. .rl.:,.,i state and

a' does contains only CreateRole, CreateOT, AddSubject, GrantRight,
AddRoleBinding, and C('!I i .OT commands.

Lemma 5 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I. .rl.:,.,i state and

a' does not contain more than one CreateRole and one CreateOT command.









Proof Let a = c a2, ..., am. We will construct a new sequence, ao, as follows:


1. Let a create i new roles, rl, r2, ..., ri.

2. Remove all CreateRole commands in a commands except the first one (only
rl is added).

3. Replace all occurrences of rj (1 < j < i) with ri in all the remaining
commands.

The roles have no pedigree (i.e., the creator of a role does not have any special

rights over the role). Therefore, if some role r' can grant a right or allow a subject

to bind to r2, then r' can do the same to rl. Since new roles have no pedigree, if

some role, r, can execute a command a that affects rj in some way, then r can

execute a to affect rl in the same way. Therefore, for a given state S, if a results in

a leaking state, then ao results in a leaking state and vice versa.

Similarly, we can remove all but the first CreateOT command from a1 and the

resulting sequence, a' results in a leaking state if a results in a leaking state and a'

contains no more than one CreateRole and one CreateOT commands. |

Remark When the only CreateRole command is executed, it activates the

NewRole attribute. Similarly, the execution of CreateOT command activates the

NewOT attribute.

Lemma 6 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a 1. a.. ,:,i state and

a' does not contain more than |TR\ + 1 AddSubject commands.

Proof By lemma 2, we can assume that a does not have any revocation or deletion

commands.









Let a contain n commands that add a new subject with the initial role

rl. AddRoleBinding is the only command other than AddSubject that directly

addresses a subject.

Let gp(k, ri) be the statement that if a adds k new subjects with initial role rl,

then there exists a sequence of commands that results in a leaking state and adds

only one new subject with initial role rl.

Base Case: k= 2

When the first subject si is created, f,(si) = {ri}. When the second subject

s2 is created, f,(s2) C fr(si), therefore, any new role binding added for s2

can also be added for sl. Let us construct a new sequence a- by removing the

AddSubject(r', ri, 82) command, replacing every occurrence of s2 with si in all

AddRoleBinding commands and retaining all other commands.

Let S -, S' and S -,, S1. By construction, Si has all the rights in Si

that S2 has in S' and neither si nor s2 were a part of S. We also know that S' is a

leaking state (since a results in a leaking state). Now, we will prove that S1 is also

a leaking state.

Case 1: The newly created subject s2 caused the leak.

If s2 gets the right p over o in S', then si gets p over o in S1. Therefore, if s2

was the cause of the leak in S', then sl will cause a leak in S1.

Case 2: The right leak was due to some other command in a.

Since all the commands other than those that have s2 as a parameter have

been retained in a-, if commands other than the ones affecting s2 caused the leak

in S', then those same commands will cause a leak in S1. Therefore, S1 also results

in a leaking state.

Hence, if a adds two new subject with initial role ri, then we can get a new

sequence that also results in a leaking state but creates only one subject with

initial role rl. Therefore p(2, ri) is true.









Induction Step: Assume p(k 1, ri) is true (k > 2).

Let the k subjects added by a with initial role be sl, 2, ..., Sk. We can con-

struct a sequence of commands, k which does not add the subject s2 but still

results in a leaking state using the construction mentioned above. Now, we have a

sequence of commands that adds k 1 new subjects with initial role rl that results

in a leaking state.

Since p(k 1, ri) is true, we can replace Uk with a new sequence a' that adds

only one new subject with initial role rl and still results in a leaking state.


p(k- 1, r ) = p(gk, r1)


Therefore, by the principle of mathematical induction, p(k, ri) is true for all

positive integer values of k. If k = 0, then we already have a sequence of commands

that result in a leaking state and adds no more than one subject with initial role

ri.

Applying the above result for every role, we can construct a sequence of

commands that add only one subject for every role in the state. By lemma 5, we

can retain just one CreateRole command in a, therefore the number of roles after

the execution of all commands is at most one more than the number of roles in

S. Therefore the new sequence will have at most ITR + 1 number of AddSubject

commands.

Each of these ITR + 1| AddSubject commands activates a NewSubject, attribute.

If the initial role of the new subject is r', then the corresponding AddSubject

command activates the attribute NewSubject,,.

Lemma 7 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:









a' also results in a 7. .r :,,i state and

a' does not contain more than Nc(S) GrantRight commands, where Nc(S)
7(ITRI + 1)(ITI + 2)(ITI + IRI + 2).

Proof We are interested only in those GrantRight commands that grant

p, ADDSUBJECT, CREATEROLE, CREATEOT, GRANTRIGHT, AD-

DROLEBINDING, and CHANGEOT rights because:


1. By the definition of access right leak problem for the DCS-AC model,
granting some role a right p' that is not one of the sixteen DCS-AC system
rights or p (the right we are interested in) does not affect the access right leak
problem.

2. By lemma 2, we are ignoring all revocation and deletion commands and by
lemma 3, we can ignore all AddObject, AddAccess, and C',ia,. I)P commands.
Since we are not executing these commands, we need not execute GrantRight
commands that allow roles to execute these commands.

Applying lemmas 2, 3, 5, and 6, we can construct a sequence of commands ac from

a that results in a leaking state and contains:


no revocation or deletion commands

no AddObject, AddAccess, or C'l,,,, I)P commands

no more than one CreateRole and one CreateOT command

no more than ITR + 1 AddSubject commands.

Let each GrantRight(r, ri, t, ot, pi) command activate the HasRightr,ot,p,,t at-

tribute. We know that pi has to be one of the seven rights identified above.

Furthermore, if a GrantRight command, aj, activates a attribute that was active

in the initial state S or was activated by an earlier command ai, we can ignore this

command since there are no revocation or deletion commands. We construct a new

sequence of commands a' from a1 that does not contain any GrantRight command

that activates an already active attribute. Since we are throwing away only those









commands that are meaningless in the context of access right leak, a' will still

result in a leaking state.

Therefore, the number of GrantRight commands in a' is no more than the

number of HasRightr',,ot',p,t, attributes (active or inactive). We know that:


number of possible values for r' is < ITRI + 1

number of possible values for ot' is < ITI + 2 1

number of possible values for p' is 7.

number of possible values for t' is < ITI + 2 + IRI (since t' c T U R).

Let S -,, S'. This means that the number of HasRight attributes in S' is no more

than 7(|TRI + 1)(ITI + 2)(ITI + 2 + IRI).

Therefore, the number of GrantRight commands in a' is no more than 7(ITRI +

1)(|TI + 2)(ITI + IRI + 2). I
Lemma 8 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I .d ':r,,j state and

a' does not contain more than NR(S) AddRoleBinding commands, where
NR(S) = (ITRI + 1)(ISUBI + TRI + 1).

Proof Applying lemmas 2, 3, 5, 6, and 7, we get a new sequence of commands ao

from a which also results in a leaking state.

Now, each AddRoleBinding(r, s, ri) command activates the CanBinds, attribute.

We construct a new sequence of commands, a' by removing all AddRoleBinding



1 We can create one new role and one new object type. Since TR C T, in the re-
sulting state, IT'I can be up to 2 more than ITI.









commands that activate a attribute that was already active in S or was activated

by an earlier command in a'.

Therefore, the number of AddRoleBinding commands in a' is no more than the

number of CanBind attributes in that instance of DCS-AC. Moreover, a' does adds

no more than one new role and no more than TRI + 1 new subjects (by lemmas 5

and 6 respectively).

Therefore, the number of AddRoleBinding commands in a' is not more than

(ITRI + I)(ISUB + ITRI + 1).

Since we are removing only those AddRoleBinding commands from a, that do

not change the state of the system, a' will also result in a leaking state. I

Definition An enabler command is a command that activates a currently inactive

attribute. Therefore, for a state S, Enabled(S) is the set of inactive attributes for

which an enabler command exists.

Definition For a given state S, we i- that a sequence of commands is monotonic

if and only if the sequence contains only enabler and C'li,,.j OT commands

Corollary 9 For a given state S, right p, and object o, if there exists a sequence

of commands a that results in a leaking state, then there exists a sequence of

commands a' that is monotonic and results in a '. r .i.:,j state.

Lemma 10 For a given state S, the set of commands that activate the attributes in

Enabled(S) can be executed in rwi,; order and the resulting state will be the same.

Proof Let A(n) be the proposition that for a sequence of n commands a (=

ac, a2, ..., an) that activate n enabled attributes, for any permutation 7r of the

commands ac, a2, ..., a, (S ~ S,) = (S -~, S,) where ac is the permuted

sequence of the commands in a

BASE CASE: n = 2 (There are only two permutations, 1, 2 and 2, 1)

a = a1, a2. Let u' = a2, a1









Let a activate the attribute Xi and a2 activate X2. Let S -, S, and

S -->7 S111.

S, is the state obtained as the result of adding the attributes X, and X2 to S

and S,, is the result of adding the same two attributes to S.

S, S,,. Hence A(2) is true.

Induction Step:

Assume that A(k) is true for all k(2 < k < n).

Let 7r be a permutation of the commands in a and let a, = a',..., a', be

the permuted sequence of commands. Furthermore, let S ---> S,. A(n) is true if

S, = ,7.

Case 1: a' = a ,

Let a-I = O', ..._ and S ,, S1. Since = an,


S1- ST (5.1)


Let Tr' be a permutation of the commands a, ..., o'-_l. Let the new sequence

formed by the permuted commands be o'-


(n 1) (s ~, Sn-1) (5.2)


Now if r' is a permutation such that r'(Tr(cai)) = ai, then


-1 a1, a2, .,an-1 (5.3)


From 5.1, 5.2, and 5.3,

S- = S, (5.4)

But, S -= S,.

.. -- .









Case 2: a, / an

Let 7(an) a (1 < j
I/ / I /
A(n 1) = S -, S,, where O" = a ', ..., a._l, Or_l, l, ,..., O-_2, O, O


A(2) = S -S 2 S', where 0r2 O-1, .j_li, O4_l, Cj+l, -..., 1n- 21, n j

Since a' an,


A(2) = S -^2 S1, where a2 = a1,..., _, O a_, jI,., -n_2 21an, 2 an

Since an is the last command, we can follow the same steps as in Case 1 and prove

that S, = S,.

.. Vk (2
By the principle of induction, since the base case is true and (Vk(2 < k <

n)A(k)) = A(n), A(n) is true for all n > 2. |

Definition Let the number of attributes that are not active in a state S be N(S).

From the above lemmas, we know that


N(S) < 1 1 1 + (TR + 1) + NG(S) + ,NR(S)


Theorem 11 The access right leak problem for a given DCS-AC state can be

decided in jp .1/;,;, ..,,/.;, time.

Proof Let the initial state be So, and let o and p be the object and right we are

interested in. We will now provide a polynomial time algorithm to decide the access

right leak problem for (SO, o, p).

We know from corollary 9 that So can lead to a leaking state if and and only if

we find a monotonic sequence of commands.

Initialization Step

We create the set InactiveAttributes which contains all attributes that are

inactive in S. Initially, InactiveAttributes = {NewRole, NewOT}.









V r E TR add NewSubject, to InactiveAttributes.

V r TR, V ot T, V p' E R, Vt (TU R)
if HasRightr,ot,p,t V Active(S) then add it to InactiveAttributes.

V s E SUB, V r ft(s), add CanBinds,r to InactiveAttributes.

The above step can be completed in O(N(So)) time. Once we have identified the

inactive attributes, we can proceed to the next step.

Saturation Step

We will now saturate the instance, i.e., activate every attribute that can be

added till nothing more can be added. Starting from SO, we execute all the enabled

commands in the current state (Si) to reach a new state (S"+1) and repeat this step

till no more attributes can be activated.

By lemma 10, we can execute the commands that enable the attributes

in Enabled(Si) in any order. We execute them all taking care of the following

book-keeping steps:


If the NewRole attribute is activated, then:
1. For all subjects currently in the system, add a corresponding attribute
(CanBinds,re,, where s is the subject and rne is the new role created).
2. For all object types, rights, and targets, add HasRightr,,, ot,p,t to
InactiveAttrinutes.

If the NewOT attribute is activated, then add corresponding HasRight
attributes.

If a NewSubjectr, attribute is activated, then for all roles rl currently in the
system other than r', add CanB.:,,. to InactiveAttributes, where snew
is the new subject added.

Remove all attributes that are activated from InactiveAttributes once the
enabling command is executed.

Repeat the above step till we reach a state S" for which Enabled(S8) = 0.

At this point the system is saturated and we cannot activate .ni, new attribute.









Since there are at most N(So) attributes, this step takes O(N(S0)2) time. We now

proceed to the next step.

Type Checking Step

Let S = (A',R', T', T,, SUB', OBJ', f', f;). Now, we can tackle the

Clri,.j, OT command as follows: We first identify the set of leaking types, LT

and then check if o can be changed to any of these types.

LT = {otlot E T' A Ks,p,ot 4so,p,fo(o) / 0}


We can identify the elements of the set LT in O(IT| ISUBI ITRI IRI) time.

Once we have identified the elements of LT, we can check if the type of o can

be changed to any of these types by creating a T iP.w. lI-,,, ie graph, G = (V, E)

where G is a directed graph such that V T' T' and


E = {(ot, ot2) ot, ot2 E T'A3r TR such that (CHANGEOT, ot, dp) E A'[r, ot2}

That is, the nodes in G correspond to object types in S8 and there is an edge from

ot1 to ot2 if some role can change the object type of an object from otl to ot2.

Now, the problem of deciding if the object type of o can be changed to one of

the .,I..,. ',,,/, is reduced to a graph reachability problem which can be solved

by performing a depth first search starting from fo(o) (the object type of o in the

initial state) and checking if the current node is in LT. If one of the types in LT

can be reached from fo(o), then there is a sequence of commands that can lead to

a leaking state else there does not exist a sequence of commands that result in a

leaking state.

The graph can be constructed in O(T|12) time and the graph traversal also

takes the same amount of time. The type checking step takes O(ITI ISUBI ITR p

IRI) time.









Of the three steps mentioned above, the saturation step takes the most amount

of time and hence the ARL problem can be decided in O(N(S)2) time. |

5.5 Summary

In this chapter, we restricted the DCS-AC model and saw how to decide in

polynomial time whether a given state could result in a leaking state by executing

an arbitrary sequence of commands if voting is disallowed. We assumed mono-

tonicity and proved that there is a polynomial upper bound on the number of

meaningful commands (i.e., commands that when executed result in a change of

state). Using this, we constructed a directed state graph where each node of a

graph corresponds to a state and two nodes are connected if there is a command

which when executed on the starting state results in the ending state.

We then identified those states which result in a leak and if there is a path

from the node corresponding to the starting state to a node corresponding to one

of the leaking states, then the system can leak the right. The commands that will

result in a leaking state is the sequence of commands that correspond to the edges

along such a path. Hence the access right leak problem for this restricted version of

the DCS-AC is decidable in polynomial time. In the next chapter, we will see how

to solve this problem if voting is allowed.















CHAPTER 6
TRUST AND VOTING

6.1 Introduction

In this chapter we will analyze the safety of the DCS-AC model where subjects

are allowed to vote. Since we cannot deterministically predict how the subjects will

vote we will approach the problem from a different angle. We assign a numerical

value, trust-level, to each subject which represents the amount of resources a

malicious entity needs to expend in order to make the subject vote against the

best interests of the group. We will identify three simple approaches on how

subjects can be I F i, 'I" and analyze the access right leak problem based on these

approaches.

6.2 Trust and Trust-Worthiness

One of the key questions in any vote is "How much can we trust the voters to

make the right decision?". There are many aspects involved in trust, some of which

are identified below:


understanding of and belief in the mission of the group

sound decision-making process

rational behavior

susceptibility to blackmail or bribery

protection of identity

Different groups give different weight-ages to these and other aspects of trust.

Based on these, we assign a trust level to each subject s denoted by 0(s), which is

the amount of resources required to turn the subject s. Our main concern here is









the susceptibility of the subjects to make a wrong decision. By wrong, we mean a

decision that is not in the best interests of the group. The subject might decide to

do the wrong thing by intention (needless to -,i, our trust level in such a person

would be low). We assume that we know the trust level of all subjects in the group

and that this trust level is constant. For the sake of simplicity, we will assume that

each subject in the system has a unique trust level.


0(s) 0(s2) S1 S2

Note that we do not talk about how the trust levels are assigned as this may vary

from group to group depending on the group proirities. We should consider all the

factors mentioned above and other aspects that the group might feel important.

We could use a reputation-based trust management scheme like the model defined

by Shmatikov and Talcott [57] or a feedback-based scheme similar to the one used

in eBay [58]. In our safety analysis, we will assume that each subject has a unique

trust-level that is assigned outside of the DCS-AC and is correct.

6.2.1 Approaching Trust

There are many v-- v of looking at trust and susceptibility. The key idea in

here is to look at trust level as the amount of resources needed to make a particular

subject or group of subjects vote in a manner that is against the best interests of

the group. With this in mind, we will now look at three different approaches to

analyzing susceptibility through trust levels as defined here.

Ad-Approach

In the first case, if someone can make a subject si make a decision in a certain

way, then that person can make any other subject 82 make the same decision in

the same way with no additional effort if 0(si) > 0(a2). We will call this the

Advertisement approach (ad-approach) since we can look at this as p liing for an

advertisement which all the voters will see. If the ad is good enough to convince si,









then s2 will also be convinced. We will use OA(s) to denote the trust in a subject s

under the ad-approach. It must be noted that in this approach, one i1l" will cover

all decisions required.

Pay-As-You-Go Approach

It is possible to bribe or cheat the voters to turn one decision at a time. This

means that more resources are required to convince the same voter if he/she gets

to participate in another decision down the line. We will call this the Pa i-,- --ou-go

approach (P-approach) and use Op(s) to denote the trust in a subject s under this

approach.

Honest Politician Approach

In the words of former U.S. senator Simon Cameron, "an honest politician

is one who when bought, stays boul!l The key idea behind this approach is

the assumption that all the subjects are hI,.i, -1 pcl i. i, ii- In this case, 0(s) is

the amount of resources that someone has to expend to make si make a certain

decision (that person has to expend 0(s2) additional resources to "turn" s2). In

addition, once bought, the subject stays bought and no additional resources are

required if the subject gets to vote on another decision later. We will call this the

Honest Politician approach (H-approach). We will use OH(s) to denote the trust in

a subject s under the H-approach.

Hybrid Approach

The approaches mentioned above are very simplistic and in reality, a mixture

of these approaches is more likely to be used. These three approaches provide a

starting point for discussion and are more useful in introducing the ideas discussed

here. We hope to extend this to model real-life approaches in the near future. We

will concentrate only on the first three approaches here.









6.2.2 Decision Templates

In order to clarify how decision templates work, let us look at a simple decision

template. Here, all votes are weighted equally and parameters like quorum, voting

period, percentage of votes required for a ;/, vote are all part of the template.

Each such voting template is represented by the tuple (VR, k, q, td, Yd) where,


VR is a set of roles that can participate in the vote,

k is a number between 0 and 1 which represents the ratio between the
minimum number of ;, votes required to pass and the total number of
participating voters,

q is another number between 0 and 1 which represents the quorum (i.e., ratio
of minimum number of voters required to participate and the total number of
voters),

td is the time duration over which the vote is active (example: 2 d4,i-), and,

yd is the default decision which is returned if the deadline has passed and the
quorum has not yet been reached.

In addition, the set of decision pointers, DT, also contains an Al, ';;,- Yes template

(dyes) which ahv-i- returns i,. The reason for this is that many decisions do not

require a vote. An example of the template is ({F ,. ,li/i, Staff}, 0.5, 0.8, 2 d A-,, N).

In this template, all subjects who can bind to the roles Faculty and Staff can par-

ticipate in the vote which requires a simple ini j. iily with at least 1II'. voter

turnout. If after 2 d4 i- the quorum is not reached, a result of No is returned. If

after two di-,, at least 1II'. of the voters have cast their votes, then a Yes deci-

sion is returned if at least half the votes cast are ;, votes, if not a result No is

returned.









In our model, each subject gets to cast one vote even if he/she can bind to

more than one role in Vp. A discussion of the actual working of the voting mech-

anism is beyond the scope of this work and we will restrict ourselves to a brief de-

scription of the life-cycle of a vote. When a group decision is called for, we instan-

tiate a vote v based on the template. V (E,, Vote,, Voted,, T,, k,, q,, default)

where:


E, is the set of all eligible voters

Vote, is a mapping between each subject and his/her vote in the decision.
The possible values are D (defer), Y (Yes), N (No), and, A (abstain)

Voted, is the set of all eligible voters who have cast a valid vote (Y, N, or, A)

T, is the deadline for the vote which is obtained by adding td to the time of
vote initialization.

k, is the value of k in the template

q, is the value of q in the template

default is the value yd of the template

E, = {s SUBVR n f,(s) 0}

Vote, : E, {Y, N, A, D}

Voted, = {s E, E Vote,(s) E {Y, N, A} }

Initially, since nobody has voted yet,


Vs E E,, Vote (s)= D


When an eligible voter, s, casts a valid vote (Y, N, or, A), his/her vote is

updated in Vote, and s is added to Voted,. When the deadline T, is reached, all

new votes are rejected and a decision is reached.









We identify the following sets:


Y, = {s E,|Vote,(s) = Y}

N, = {s E,|Vote,(s)= N}

A, = {s e E,Vote(s) = A}

We first check for the quorum,
Voted, >
IEJ -
if this is false, we return the default decision. If every subject who voted has

abstained, (|Y, + N1, = 0), we return the default decision. Next, we check if

enough yes votes have been cast.

IY >k
>k
IY, + N, -

if this is true, we return yes and we return no otherwise.

6.3 ARL Problem And States

Since excecution of certain commands is dependent on the subjects who are

allowed to vote, we have to factor our trust in the subjects while deciding the

safety of the system. With this in mind, we redefine the access right leak problem

for a DCS-AC system with voting as follows:

Definition For a given state So, object o, right p, and, budget T, the access

right leak problem (ARL) is a decision problem, does there exist a sequence of

commands in So with trust level less than T that results in a leaking state.


ARL {< S, o, p, T > 13a such that So -- St and


St,p,f,(o) so,p,fo(o) / 0 and'(a) < T}

where (a) is our trust in the sequence of commands a by applying one of the

three approaches.









In other words, can a malicious party, with a given budget, corrupt enough voters

to enable an unauthorized subject access to an object.

Let N,(SO) denote the number of commands that can be executed on the

initial state SO and all its descendent states. We are only concerned with the

commands CreateRole, CreateOT, GrantRight, AddSubject, AddRoleBinding, and

C'li,,,. OT (this is due to Corollary 4). As proven in the lemmas 3, 5, 6, 7, and 8,

the total number of such commands is bounded.
N,(So) < 1 + 1 + (ITRI + 1) + NG(S) + NR(S) + (T TR + 1)

< 4 + N(S) + N(S) + ITI
Definition For a given DCS-AC system with initial state So, we define the set of

all possible reachable states, SO as follows:

So {SI(S So) V (ca such that S'- S A S' E S)}


The size of this set is dependent on the number of commands that can be executed

on the initial state and its descendants. Each state can be represented by a N,(So)-

bit number where each bit corresponds to a particular attribute. The bit is 1 if the

corresponding attribute is active in that state and 0 otherwise.


o0o1 < 2N1(s0)

6.4 Trust Analysis of DCS-AC

Let us now prove the tractability of the ARL problem for a DCS-AC system.

As mentioned earlier, we will use the trust-worthiness of subjects to decide on the

trust-worthiness of the system.

6.4.1 State Graph

We will now construct a directed graph Gso = (V, E) which corresponds to a

DCS-AC system with the initial state So (We will call this graph the State Graph

of SO). The set of vertexes is V = S and there is an edge from vertex Si to Si









labeled (a, r) if S" is the result when a subject bound to the role r executes the
command a in S'.

Since each state has a unique set of properties, there cannot be more states
than the total number of properties in any given path.

VI = 1S < 2N(so)

In any given state, we cannot execute more than N,(So) commands and each of

these commands can be executed by at most ITp roles.

El < IV1 ITRI (S N s) < TR I N0(SO) 2N(S)

If we use an .,1i ,i:ency list, we can construct the graph in O(|IE). Therefore, the
graph can be constructed in O(ITRI N(So) 2 (So)) time.

Let SL denote the set of all leaking states.

SL = {S( Se s1,ot,p )S0,fo(o),p 0}

As mentioned in the previous chapter, we can identify the elements of SL in
O(IV ITI TRI ISUBI IRI) time.

Before looking at the three approaches to trust from the DCS-AC point of

view, let us define a few useful sets. For a decision d = (VR, k, q, Yd, td), let W(d)
be the set of r(d) weakest (in terms of susceptibility) voters. These voters are the

most likely to vote against the best interests of the group.

W(d) = {s s c V(d) A s, S2, ..., T(d) C V(d) such that


i / j Sz / sj A Vie [1, r(d)] 0(sj) < 0(s)}









For a command a, let W,(a) denote the set of voters that are most likely to vote

against the best interests of the group.


Wc(a) = W(d)

where d is the decision that guards the command. Moreover, some subject has

to issue the command in order to execute it. Therefore, our trust in a command

has to include our trust in the role that can issue the command. Let 7(r) denote

our trust in a role r. Our trust in a role is the same as our trust in the least

trustworthy subject that can bind to that role.


7(r) = min{0(s)|s E SUB and r E f,(s)}

Needless to -iv, our trust in the decision pointer dyes is 0.

6.4.2 Ad-Approach

Let OA(d) denote our trust level in a decision. In ad-approach, OA(d), is the

maximum trust level of all the voters in W(d).


OA(d) = max {OA(s)| s c W(d)}

Let d be the decision template that guards a command a. If the right that guards

a is enabled, then we can trust a only as far as we can trust d. Let QA(a) denote

our trust level in a command a. Here, we are looking at the command by itself

with no prior "history". There may be more than one role that can issue the

command. Let rl be the least trust worthy of all the roles that can execute the

command.


QA(a) = max(OA(d), y(rl))









Now, for a given sequence of commands a(= a a2, ..., On), let 'A(a) denote the

trust level in a using the ad-approach.


TA( ) = A( i) such that Vj E [1, n], A(Qj) < A( i)

In order to determine the minimum cost required to ensure a leaking state, we

have to find a path from So to SL that has the least TA value. We achieve this by

doing a modified depth first traversal on the graph.


Function DFT(v)

//The array visited[] is global and initially set to false

//The value MinCostA(SO) is initially oo

//The stack is initially empty.


1. visited[v] = true

2. if v = SL then
(a) let a be the sequence of commands in the stack
(b) c = 'A(sigma)
(c) if (c < MinCostA) then MinCostA = c
(d) return

3. for each u such that (v, u) E E
(a) if visited[u] = false then
i. push a into stack where a is the label of the edge (v, u)
ii. DFT(u)
iii. pop a from stack

We invoke this function by calling DFT(SO).

< S, 0, p, T > ARL t T >_ MinCostA(SO)

The above depth-first traversal can be completed in O(IEI) time. Hence the ARL

problem using the Ad-approach can be solved in O(ITRI 2Nv(S)) time.









6.4.3 Pay-As-You-Go Approach

Let Op(d) denote our trust level in a decision. In this approach, Op(d), is the

maximum trust level of all the voters in W(d).


Op(d) Op(S)
sCW(d)

Let d be the decision template that guards a command a. If the right that guards

a is enabled, then we can trust a only as far as we can trust d. Let Qp(a) denote

our trust level in a command a. Here, we are looking at the command by itself

with no prior "history". If r, is the least trust worthy role that can issue the

command a,

Qp(a) Op(d) + 7(r)

Now, for a given sequence of commands a(= ac, a2, ..., a,), let p(cr) denote the

trust level in a using the this approach.


Ip(a7) -Y p(5)
ai E

In order to determine the minimum cost required to ensure a leaking state,

we have to find a path from SO to SL that has the least 'p value. We achieve this

by using the single-source shortest path algorithm starting from SO. For each edge

(Si, Sj), the edge weight is bp(a) where a is the label of the edge.

Let the minimum cost to reach SL be MinCostp(So).


< So, 0, p, T > ARL # T > MinCostp(S)

Here again, the single source shortest path takes O(IE|) time (since we are using

.,1i ,i:ency lists) and hence the ARL problem can be solved using the P-Approach in

O(ITRI 2N^(o)) time.









6.4.4 Honest Politicial Approach

In the Honest Political approach, a subject once "bou, hli stays bought. There

are two problems with applying an algorithm similar to the ones used for the other

approaches. Consider the two decisions d, and d, and two subject sl and sa such

that: (i) sl and s2 are both valid voters for dl and s2 is a valid voter for d2, and (ii)

si is among the potentially weak voters in d, while s2 is not.


sl, 2 E Voters(di) and s2 E Voters(d2)


si E W(di) and S2 V W(di)


1. If S2 E W(d2), i.e., 82 is among the potentially weak voters in d2, then instead
of spending resources on both si and 82, a malicious entity can "buy" only S2
and still get both the decisions thus saving on the resources required to buy
81.

2. If S2 V W(d2) but there exists a subject S3 G W(d2) such that OH(si) +
OH(S3) > OH(s2), then it would be cheaper to buy s2 instead of both si and
S3.

The above two scenarios can be extended to any number of subjects and any

number of decisions such that replacing a single subject can lead to a cascading

effect on other decisions if the subject being replaced is among the weak voters in

the other decisions.

As we can see, the main problem is with voters who can participate in more

than one decision in a sequence of decisions. Our solution to this problem is very

simple. If a subject si with a trust level of OH(81) participates in n(< 1a ) decisions

in a sequence of commands a, then let 0'(si) denote the cost per decision in the

sequence.

e(sl) 81









Let the set V(o) denote the set of all voters in all the decisions in a.


V(a) = U,,GVoters(di) where dtis the decision that guards ci


Let W,(a) denote the minimal set of voters required to get all the decisions in a.

Let us now look at an algorithm to find this set.


Function Ws(a)

//Returns the minimal set of voters

//Initially W, is an empty set


1. sort all subjects in V(a) according to their 06

2. For each c in a
(a) Let di denote the decision guarding c
(b) Let count be the number of voters in ai already bought. count
|Voters(di) n Ws\
//We now have to find T(db) count eligible voters
(c) while count < 7(di)
i. Find s E Voters(di) Ws with smallest O8
ii. Add s to Ws
iii. count = count + 1

3. Return W,

Now, let 'H(a) denote the trust level in a using this approach.


TH(a) > OH(S)
sew,(<7)

In order to determine the minimum cost required to ensure a leaking state, we

have to find a path from So to SL that has the least 4H value. We achieve this by

using the DFT algorithm given above (we calculate 4H and MinCostH instead of

TA and MinCostA.


< S0, Op, T > ARL # Tr > MinCostH(SO)









We know that the length of the longest possible sequence is N,(So). We also

know that the maximum number of voters that can participate in a decision is

ISUBI. Hence, we can find the 4H for any sequence of commands in O(ISUBI

N0(So)) time. Therefore, we can decide the ARL problem using the H-approach in

O(|SUBI N,(So) ITRI 2N(S)) time.

6.5 Summary

In this chapter we looked at the safety analysis of the DCS-AC model with

voting. We assumed that each subject has a numerical trust-level and introduced

three approaches to trust and susceptibility namely, Ad, Honest Politician and

Pay-As-You-Go. We then saw how to determine the trust in a vote, a command

and a sequence of commands based on each of these three approaches. With this

as building blocks, we analyzed the safety of the DCS-AC model with a modified

access rights leak problem.

The key idea in the Ad-approach is that if a malicious entity can convince a

subject, s, to vote in a manner that is not in the best interests of the group, then

that entity does not need any additional resources to convince another subject

whose trust level is less than that of s. In the Pay-As-You-Go approach, each

subject has a specific amount of resources required to make him/her vote in a

manner that is not in the best interests of the group and the malicious entity

has to expend additional resources for every other subjects and also for the same

subject if he/she is required to vote again in another decision.

The most complex of the three approaches is the Honest Politician approach,

in which, a subject is "bou,!3l for the entire set of decisions. This complicates

the safety analysis since a malicious entity is better off spending resources on a

more expensive subject who can participate in many decisions as opposed to a large

number of less trustworthy subject each of whom can participate in one decision.







83

In order to solve this problem, we looked at cost per decision while deciding the

least expensive set of voters.

In each of these three approaches, we construct a directed graph which we

call state graph and use graph traversal algorithms to solve the access right leak

problem. There is a combinatorial explosion of the number of states and we proved

the decidability of the ARL problem in each of these three approaches by providing

exponential time algorithms.















CHAPTER 7
NEXT STEPS

The model as presented is powerful, flexible and scalable. However, more

work needs to be done in order to make this model model real-life policies. Some

of these are enhancing the commands in the model, extending the model itself to

allow subject-to-object privilege definitions, incorporating a role hierarchy and

time-limited access rights. As mentioned earlier, a 1 i i,' feature of the DCS model

is the use of decision templates which can protect against single malicious user

attacks. Further work needs to be done in analyzing multi-user collusion attacks.

7.1 Enhancing DCS Commands

There are some additions that can be done to improve the model. The com-

mands as described here are all mono-operational (i.e., perform only one primitive

operation). In many cases, the subject creating a new object has some special

rights with respect to that object, i.e., the creator has the right to read/write the

object or grant rights to others. While someone has the GrantRight privilege for

objects of that type, this issue is more critical for creation of new roles and object

types. If someone creates a new role or object type, the usability of this new role or

object type is severely restricted if no one has the right to allow subjects/objects

to bind to that role/object type. Therefore an additional operation needs to be

performed that allows the creator's role some basic rights.

The safety analysis needs to be revisited since the roles and object types have

pedigree and we will have to factor this into the analysis. However, the resulting

system would be more usable.









7.2 Special Relations

We would like to be able to specify subject-to-object level access rights, for

example, even though all programmers have the right to read any code, only the

programmer who wrote a particular class has the right to modify it. We can imple-

ment this by creating a new object type or a new role for each class/programmer.

This is inefficient and a simpler way is to use Special Relationships. These are a

mapping from (subject,object) pairs to roles. (fs SUB x OBJ TR). We can

define a role Class Writer and specify fs(Pi *.,1'1ii r, class) = {ClassWriter}

for each class. Now, each time an access request is made, we should check for any

special relations between the subject and the object before checking for the role

and object type (the reason being, special relations are usually more "pc .- ilil!

than regular roles for that particular object). This clearly changes the definition of

all the commands and the safety analysis but provides a very useful way to specify

finer-grained access control.

7.3 Role Hierarchy

One of the 1 i i" differences between the roles as used in the DCS model

and RBAC is role ,, 'r,. /I,; We can implement role hierarchy by maintaining a

partial ordering of the roles in the form of a directed graph, GR = (V, E) where

V C TR and (ri, r2) E E if and only if r1 inherits all the rights from r2. When an

access request is made, we first check for special relations, failing which the rights

of the user's role is checked. If this fails, a breadth first search is performed on GR

with the mode corresponding to the user's role as the starting point. At each node

visited, the corresponding role is checked for the right to perform the requested

access. We use breadth first search instead of depth first search since roles higher

up on the hierarchy are more "pcv.-v, !Ili than those further down the graph. It

might be useful to constrain the role ordering to be ... i-, i for security purposes.

This can be ensured if the role hierarchy can be specified only when the role is









defined and cannot be changed. This is too rigid and can hurt the utility of the

model. Therefore, we can allow the hierarchy to be changed anytime but the graph

could be checked for cycles before committing the change. Since the role graph is

not likely to change frequently, this is an acceptable overhead on performance. The

addition of role hierarchy increases the overhead while searching for all the users in

a role1

7.4 Use-Cases and Scenarios

One of the most important steps in proving the usability of the model is to

identify various scenarios and show how this model can be used there. For example,

we can model the CISE department in terms of subjects, roles, objects, etc. and

show how we can use the DCS model (Only Ph.D. candidates can register for

doctoral research credits and a Ph.D. student can bind to the Ph.D. candidate role

if his/her supervisory committee chair nominates him/her and all the members

of the committee agree). One other scenario we can consider is the operations of

a large organization like IEEE. The idea is to show how the DCS model can be

used in these scenarios, starting from bootstrapping the system to getting it fully

functional.

7.5 Multi-User Collusion Attacks

The use of decision templates makes the DCS model very powerful and helps

minimize the role of the local domain system administrators. This also opens up an

interesting area of research, multi-user collusion attacks. For a given state of the

system, if a group of subjects want to tip a vote (with a given decision template,

dpl) in their favor, and they try to do so by allowing some of their buddies to

bind to some roles which participate in that vote, how many AddRoleBinding



1 We may have to find the list of all users who can bind to a role for voting and
notification purposes.









commands do they need? If the AddRoleBinding commands require another vote

(Z-1, dp2), they will have to be able to carry those votes in order to get a favorable

result for dpi. The question is, for any given dpi and dp2, the minimum number of

"conspirators" required to win the vote dpl is the minimum number required to win

dp2. A more complex case is when you need to control two votes, dp2 and dp3 to

win dpl.

7.6 Time-Limited Access

Another useful addition is Time Limited Access (TLA)2 Instead of

returning a simple yes/no answer, the decision pointer could return the time for

which the access is valid. If the access is denied, then it returns a zero else it

returns the time for which the access is valid. During that time, the user is granted

access to the object without starting the decision-making mechanism. This is very

useful for pn. ':;: -;" or substitutes. For example, if the user Alice who can bind to

the role Instructor is leaving town for a week, she can allow Bob (bound to role

TA) to temporarily bind to the role Instructor. We can also create a new role

sub Instructor with a subset of the rights of Instructor. For example, Bob can

not assign grades to the students. In order to implement TLA, we need a separate

data structure that stores the time period of validity. The TLA structure should

either periodically remove expired entries or check for validity each time an access

is requested. This again might increase the turn-around time for an access request

but on the other hand, it can be very useful since it can help avoid frequent calls to

time consuming decision pointers.


2 TLA could also stand for Three-Letter Acronym















CHAPTER 8
CONCLUSION

The access control model described here is designed for the Distributed

Conferencing System version 2 (DCS v.2). However, this model can be used in

any distributed system that requires highly available access control services and

user driven decision making capabilities. We have formally specified the model

and analyzed its various advantages with respect to existing models. We have also

provided algorithms to map a state in a DCS system to an equivalent HRU state

and vice versa and proved that the access right leakage problem is decidable in NP

time. The software project example illustrates the usefulness of this mode. As seen

in chapter four, this model satisfies many interesting properties of access control

systems and supports user-defined voting templates. The presence of decision

templates allows the members of the group to decide on their own group policies

and vote on important decisions. This democratic approach ensures .fiii,, 1.r: for

the groups and provides greater flexibility in terms of access control.

We have shown that the model is provably safe in terms of the access rights

leak problem. Since some of the access control decisions are made through voting,

the security of the system depends on our trust in the voters. This leads us to the

three approaches to trust that are mentioned here. The Ad-Approach is simplistic

and the analysis is very straight forward. The Pay-As-You-Go approach is slightly

more complicated and the Honest-Politician approach is the most difficult of the

three to analyze. In all three approaches, we reduced the problem to some form of

graph reachability and have provided algorithmic solutions to the same.

This type of analysis can help us prepare against multi-user collusion attacks

and is heavily dependent on accurately assigning trust-levels to all the subjects.







89

In reality, a hybrid of these three approaches is likely to be used and this work

provides a starting point for further work in this area. In conclusion, the model

presented here is scalable, useful, provably secure, and very flexible.















REFERENCES


[1] B. W. Lampson, "Protection," in Proceedings of 5th Princeton Symposium on
Information Sciences and S1;-/. i- Princeton, 1971, pp. 437-443.

[2] G. Scott Graham and Peter J. Denning, "Protection-principles and practice,"
in Proceedings of Spring Joint Computer Conference. AFIPS, 1972, pp.
417-429.

[3] Steven J. Greenwald, "A new security policy for distributed resource man-
agement and access control," in Proceedings of the 1996 Workshop on New
S.. -,, P',,,n.,- 1996, pp. 74-86, ACiM Press.

[4] Markus Lorch and Seth Proctor and Rebekah Lepro and Dennis Kafura and
Sumit Shah, "First experiences using XAC'\ 11 for access control in distributed
systems," in Proceedings of 2003 ACI[\ Workshop on XML '.. i;,i, 2003, pp.
25-37, AC\ I Press.

[5] Ian Foster and Carl Kesselman and Gene Tsudik and Steven Tuecke, "A
security architecture for computational grids," in Proceedings of the 5th AC I[
Conference on Computer and communications ,. .ii;~ 1998, pp. 83-92, ACMi\
Press.

[6] M. Webb and D.L. Wilson R.E.N. i.--i ,i-Wolfe and C.L.Ramirez and H.
Pelimuhandiram and M. Montes, "A brief overview of the dcs distributed
conferencing system," in Proceedings of Summer Usenix Conference, Nashville,
TN, 1991, USENIX, pp. 437-452.

[7] Andras Belokosztolszki and Ken Moody, \ I i-policies for distributed
role-based access control systems," in P -1.. 2002: IEEE 3rd International
Workshop on Policies for Distributed S- ,'ii- and Networks, 2002, pp. 106
115.

[8] Anek Vorapanya, Lr,,,.--Scale Distributed Services, Ph.D. dissertation,
University of Florida, 2000.

[9] James Gosling and Bill Joy and Guy L. Steele Jr. and Gilad Bracha, The
Java LI'..i',i,': Sp / ....:.,,/,n, Addison-Wesley Professional, Boston, MA, third
edition, 2005.

[10] Herbert Schildt, Java: The Complete Reference, J2SE 5 Edition, McGraw-Hill
Osborne Media, 2004.




Full Text

PAGE 1

VOTINGENABLEDROLE-BASEDACCESSCONTROLMODELFOR DISTRIBUTEDCOLLABORATION By VIJAYMANIAN ADISSERTATIONPRESENTEDTOTHEGRADUATESCHOOL OFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENT OFTHEREQUIREMENTSFORTHEDEGREEOF DOCTOROFPHILOSOPHY UNIVERSITYOFFLORIDA 2005

PAGE 2

Idedicatethisworktomyparents,S.V.S.andPadmaManian.

PAGE 3

ACKNOWLEDGMENTS IwouldliketothankDr.RichardNewmanforgettingmestarte donthis project.IwouldliketoexpressmygratitudetoDr.SteveThe bautforhiswillingnesstohelpmewheneverIhadaproblem.Iwouldalsoliketoth ankalltheDCS groupmembers,pastandpresent,fortheirinvaluablecontr ibutionswithoutwhich Iwouldnothavebeenabletocompletethisdissertation. SpecialthanksareduetoSalilGokhaleforhelpingmestayon trackduringthe laststagesofmyPh.D.Finally,Iwouldliketothankmyparen tsfortheirsupport andencouragement. iii

PAGE 4

TABLEOFCONTENTS page ACKNOWLEDGMENTS.............................iii LISTOFTABLES.................................vii LISTOFFIGURES................................viii ABSTRACT....................................ix CHAPTER 1INTRODUCTION..............................1 1.1Motivation...............................2 1.2SampleScenario............................4 1.3OrganizationofthisDissertation.................. .6 2DCSOVERVIEW..............................7 2.1Introduction..............................7 2.2Defnitions...............................8 2.3ATypicalDayatWork........................9 2.4Services................................10 2.4.1CoGManager(CM)......................10 2.4.2NotifcationServices(NTF)..................10 2.4.3DatabaseServices(DBS)...................12 2.4.4DecisionSupportService(DSS)...............12 2.4.5AccessControlServices(ACS)................12 2.4.6SecureCommunicationsServices(SCS)...........13 2.4.7DistributedFileServices(DFS)...............13 2.4.8ApplicationManager(AM)..................14 2.4.9Tools..............................14 2.5InteractionWithOtherServices...................1 4 2.5.1InteractionWithDBS.....................15 2.5.2InteractionWithCM.....................15 2.5.3InteractionWithDSS.....................15 2.6Summary...............................15 3BACKGROUND...............................17 3.1Introduction..............................17 3.2AccessControl.............................17 iv

PAGE 5

3.3AccessMatrixModels.........................18 3.3.1HRUModel..........................19 3.3.2TypedAccessMatrix.....................20 3.3.3AccessControlinUNIXOperatingSystem.........23 3.4Role-BasedAccessControl(RBAC).................25 3.5DistributedCompartmentModel..................26 3.6AccessControlforCollaborativeEnvironments....... ....28 3.7TrustandVoting...........................30 3.8Summary...............................31 4THEDCS-ACMODEL...........................33 4.1Introduction..............................33 4.2TheDCS-ACModel.........................33 4.3Operations...............................36 4.4CommandsinDCS-ACModel....................39 4.4.1Constraints...........................41 4.4.2ExpressivePower.......................43 4.5Comparisonwithexistingmodels..................44 4.6FeaturesofDCS-ACModel......................45 4.6.1DecisionTemplates......................46 4.6.2DynamicTypeBinding....................47 4.6.3DynamicsetofAccessRights.................47 4.6.4DynamicsetofObjectTypes.................48 4.6.5FineGrainAccessControl..................48 4.7DCS-ACModelSolutionforSoftwareProjectExample.... ..49 4.8Summary...............................51 5SAFETYANALYSIS.............................52 5.1Introduction..............................52 5.2Defnitions...............................52 5.3AttributesofaState.........................54 5.4Proofs.................................55 5.5Summary...............................68 6TRUSTANDVOTING...........................69 6.1Introduction..............................69 6.2TrustandTrust-Worthiness.....................69 6.2.1ApproachingTrust.......................70 6.2.2DecisionTemplates......................72 6.3ARLProblemAndStates......................74 6.4TrustAnalysisofDCS-AC......................75 6.4.1StateGraph..........................75 6.4.2Ad-Approach..........................77 6.4.3Pay-As-You-GoApproach...................79 v

PAGE 6

6.4.4HonestPoliticialApproach..................80 6.5Summary...............................82 7NEXTSTEPS................................84 7.1EnhancingDCSCommands.....................84 7.2SpecialRelations...........................85 7.3RoleHierarchy.............................85 7.4Use-CasesandScenarios.......................86 7.5Multi-UserCollusionAttacks.....................8 6 7.6Time-LimitedAccess.........................87 8CONCLUSION................................88 REFERENCES...................................90 BIOGRAPHICALSKETCH............................95 vi

PAGE 7

LISTOFTABLES Table page 3{1PrimitiveOperationsinHRUmodel................... 19 3{2PrimitiveOperationsinTAMmodel................... 21 4{1ExampleofDCS-ACMatrixFragment..................3 6 4{2SpecifcationofDCS-ACOperations.................. .37 4{3DCS-ACSolutionforSoftwareProjectExample......... ...50 vii

PAGE 8

LISTOFFIGURES Figure page 1{1ClassLibraryScenario..........................5 2{1ArchitectureofDCS...........................11 4{1ComparisonofHRU,TAMandDCS-ACmodels............44 viii

PAGE 9

AbstractofDissertationPresentedtotheGraduateSchool oftheUniversityofFloridainPartialFulllmentofthe RequirementsfortheDegreeofDoctorofPhilosophy VOTINGENABLEDROLE-BASEDACCESSCONTROLMODELFOR DISTRIBUTEDCOLLABORATION By VijayManian December2005 Chair:RichardE.NewmanMajorDepartment:ComputerandInformationalSciencesand Engineering Thisdissertationpresentsavotingenabledrole-basedacc esscontrol(RBAC) modeldesignedfordistributedcollaborationthatallowst hegrouptodecideand implementgrouppolicies.Thismodelcanalsobeusedinmany middle-level systemsthatrequiresupportforgroupvoting.Theprimaryg oalsofthismodel aresecurity,scalability,rexibilityandsimplicity.One ofthemajordrawbackswith manymodelsinusetodayistheneedforanexternaladministr atororauserwith \god-level"powerstoimplementthegrouppolicies.Weover comethisbyallowing subsetsofuserstovoteonaccesscontroldecisionsthatare deemedimportant. Thistakestheburdenofgroupmanagementfromthesystemadm inistratorsand allowsthegrouptobetrulydemocraticandautonomous.Inth isdissertation,we givethemotivationforthemodel,formallydeneitandgive anexampleofhow itcanbeused.Wealsodenetheaccessrightleakageproblem whichweuseto analyzethesafetyofthemodel.Werstprovethatforasimpl eversionwithout anyvoting,theaccessrightleakageproblemcanbedecidedi npolynomialtime. Wethenintroducethenotionof trust-level anddiscusshowthetrust-levelof theusersaectthesafetyofthesystem.Thisdissertationi dentiesthreesimple ix

PAGE 10

approachesbywhichamaliciousentitycancausegroupmembe rstovoteina mannerthatisnotinthebestinterestofthegroup.Wethenan alyzethesafetyof themodelundereachofthesethreeapproaches. x

PAGE 11

CHAPTER1 INTRODUCTION Distributedcollaborationismorethanjustabuzzwordinto day'sworld. Mostusersloginfromlargenetworks,andoftentimes,theco llaboratorsarefrom dierentadministrativedomains.Insuchascenario,acces scontrolcanbecome anadditionalburdenonthealreadyoverworkedadministrat orsandusuallyis dicultwithoutenforcingmanyrestrictions.Onastand-al onemachine,access controlismoreorlessstraightforwardwiththeoperatings ystemprovidingsimple discretionaryaccesscontrol(DAC)mechanismslikeaccess controllists(ACL)or capabilitylists(CL).Mostofthesemechanismsarebasedon theaccesscontrol matrix(ACM)model[1,2].Variousmodelshavebeenproposed formulti-user systemsandthesemodelsaredenedwithwell-knownabstrac tionslikesubjects, objectsandaccessrights. Therearesomemajordisadvantagestothecurrentmodelswhe napplied todistributedenvironmentsingeneralanddistributedcol laborativesystemsin particular.Mostsystemstodayarerunoverthenetworkandh aveacentralized nodetohandleaccesscontrol,whichresultsinasinglepoin toffailureandmore importantly,asingleadministrativeauthority,whichisn otalwaysdesirable.Many practicalmodelsrestrictthetypesofaccesses(forexampl e,Unixhasonlythree types:read,writeandexecute),whichdoesnotrerectreall ife.Inaddition,each objectinthesystemcanhaveonlyoneowner,whichmightnotb ethecaseina collaborativeenvironment.Someofthemajorproblemswith classicalmodelsare discussedinsection1.1. TheDistributedConferencingSystem-AccessControlModel (DCS-AC) discussedinthisdissertationhasbeendesignedtoprovide asimple,powerful, 1

PAGE 12

2 implementable,scalableandrexibleaccesscontrolmechan ism.Oneofthemost importantfeaturesofthismodelistheuseofgroupdecision -makingmechanisms (voting)asapartoftheaccesscontroldecisionprocess.He re,importantaccess controldecisionscanbereferredtoavoteamongaspecieds ubsetoftheusers, therebyallowingthemtoself-administerthegroups.Manyc urrentmodelsrely ona\superman"whocandoalmostanythinginthesystem.TheD CSapproach modelssocietymorecloselyandalsoprotectsthesystemaga instmalicioussingleuserattacks. WeanalyzethesafetyofthemodelintermsoftheAccessRight sLeakage (ARL)problem.ARListheproblemofdecidingwhetheramalic iousentitycan executeasetofcommandswhichresultinanunauthorizeduse rgainingaccessto anobjectinagivenDCS-ACinstance.Weapproachthisproble mbyrstsolving itforasystemwithnovoting.Whenthesubjectsareallowedt ovoteononeor moreaccesscontroldecisions,itisdiculttodecideonaye sornoanswer.We assignatrust-levelvaluetoeachsubjectanddecideonthea nswerintermsof thetrust-levelsofallthesubjectswhocanparticipateint hevote(s).Letusnow considerwhyweneedtheDCS-ACmodel. 1.1 Motivation Mostaccesscontrolsystemsinusetodayarebasedonthetrad itionalaccesscontrolmatrixmodel. 1 Thisproposalconsidersaccesscontrolpoliciesina distributedcollaborativeenvironmentwherethetraditio nalmodelssuerfrom thefollowingproblems(afewmoreproblemswithcurrentsys temsaregivenin Greenwald[3]). 1 ACLandCLcanbeconsideredtobeapartofthetraditionalacc esscontrol matrixmodel

PAGE 13

3 1.Systemadministratorsareusuallyoverworkedandunderp aid.Acentralized serverthatcoordinatestheentiredistributedsystemwill notworkwell. 2.Ifthreesubjectsarecollaboratingonadocument,undert hecurrent paradigm,anyoneofthesethreecanunilaterallydeletethe object.This isnotdesirableandamoreusefulpolicycouldbetorequirea tleasttwoof theauthor'sapprovalinordertodeletetheobject. 3.Itisdiculttoobtainaccesstoobjectslocatedinadier entadministrative domainwithoutgettingthelocalsystemadministrator'spe rmission. 4.Eveninsystemsthatarespecicallydesignedfordistrib utedcomputing[4], likegridcomputing,thestandardpolicyisforeachdomaint oberesponsible fortheobjectsinitssite[5].Now,ifAliceaccessesanobje ctfromanother administrativedomain,acopyoftheobjectisusuallycache d.Thelocal systemhasnoideaabouttheaccesscontrolpoliciesofthiso bjectandwhen Bobrequestsaccesstothesameobject,therequestisforwar dedtotheother domain.Ifthelocalsystemwereawareoftheaccesscontrolp oliciesforthe object,itcouldhavemadethedecisiononitsownandsavedBo balotof time. 5.Theindividualgroupsofcollaboratorscannotsettheiro wngrouppolicies. TheDCS-ACmodeladdressestheseissuesandprovidesaveryr exibleaccess controlmechanism.ThismodelwasdevelopedforDistribute dConferencingSystem (DCS)[6],adistributedcollaborativearchitecturethata llowsusersfromdierent sitestoworktogether.TherstobjectiveoftheDCS-ACmode listoprovide rexible,implementableandfaulttolerantaccesscontrol. Thesecondobjectiveis toallowtheusersofthesystemtoself-administertheacces sprivileges,i.e.,allowa subsetofusers(whoareoftenthestakeholders)tomakeacce sscontroldecisionsfor importantobjectsonacase-by-casebasis.Thisisdonebyus ingasetofdecision templateseachofwhichdenesthesubsetofusersthatcanpa rticipateinavote. EachentryintheACMhasadecisiontemplatepointerwhichha stobeexecutedinordertoarriveatadecision.Althoughthemodelenf orcesnoconstraints onwhichdecisionsrequireavote,weexpectthatmostentrie swillpointtothe Always-yes templatewhichalwaysreturnsa yes sincemanyrights,oncegranted,

PAGE 14

4 neednotbereferredtothevotinggroupforeveryaccess.How ever,forimportant accesscontroldecisionsthesystemcanreferthedecisiont oasubsetoftheusers whovoteonit.Thisallowstheuserstoexpressaccesscontro lpoliciesforsome accesses(likejoiningthegroup,accessingimportantobje cts,grantingaccessrights, etc.)inthesystem. Theuseofdecisionpointersalsoimprovesfaulttolerance. Itprotectsagainst singlemalicioususerthreats,sincemanyusersmayhavetoa greeforthevote topass.Inaddition,ifsomeoftheusersareunavailable,th esystemcanstill takedecisionsbasedontheusersavailable(unlessthesyst empolicyspecically statesthataparticularusermustagreeforthevotetopass) .Therearemany real-lifescenariosinwhichsuchmulti-userauthorizatio nsarerequiredandareoften handledo-linebeforeoneoftheparticipants\informs"th esystemiftherequestis approved. 1.2 SampleScenario Considerthefollowingexampleofaprojecttobeimplemente dbyateam consistingofa projectleader (PL)andmanysubordinates( architect s, programmer s and tester s).The architect sworkonthedesignandoncethedesignisapproved bythePL,oneormore programmers codetheproject,whichisthentestedby the tester s.Thetesterscaneithersenditbacktotheprogrammersalon gwitha bug-listornotifythePLthatthecodeisacceptable.ThePLt henreviewsthecode withthereviewteam,andifapproved,theprojectisrelease dtotheclient(referto Figure1{1). Givenbelowareafewcompanypoliciesapplicable. 1.Theindividualsconcernedmaybelocatedindierentbran ches;condentialityandavailabilityareimportantforthesharedobjects. 2.Thearchitectdoesnotneedaccesstothecodeandtheteste rcanlookatthe codeonlyaftertheprogrammersareready.

PAGE 15

5 to client Code released Problem Statement Design Document Bugs-ListCode Code Tester Team Review Programmer Architect PL Figure1{1:ClassLibraryScenario 3.ThereviewteamconsistsofallPLsinthecompanyandtheme mbersdonot haveaccesstothecodeuntilitpassesthetestingphase. 4.ThePLcanaccessanydocumentrelatedtothisparticularp rojectatany pointoftime. 5.ThePLalsodecideswhoworksonthisproject.6.ThePLcannotchangetheroleofanemployee;forexample,t hePLcannot assignaprogrammertodothetaskofanarchitect. 7.Therearemanyarchitects,programmers,etc.inthecompa ny,andonlythose involvedindevelopmentshouldhaveaccesstotheobjects. 8.Theprogrammersdoaninternalreviewandsendthecodetot hetestersafter everyprogrammerhasapprovedit. 9.Thereviewteammembersvoteonwhetherthecodecanbeadde dtothe library. ThersteightrequirementscanbehandledbyRBACinastraig htforwardmanner usingconstraints.However,specifyingconstraintsintro ducesruntimeoverhead [7].Requirementseightandnineinvolvegroupdecisions.A lthoughtheabove exampledealswithasimplisticscenario,webelievethatth erearemanyexamples

PAGE 16

6 thatinvolvesimilarissues.TheDCSmodelisdesignedtohan dlescenariosofthis nature. 1.3 OrganizationofthisDissertation Chapter2givesabriefoverviewoftheDistributedConferen cingSystemand chapter3providesthetechnicalbackgroundfortheDCSacce sscontrolmodel. Chapter4dealswiththeformaldenitionoftheDCSModeland discussesthe featuresoftheDCSmodel.Chapter5discussesthedecidabil ityoftheARL problemfortheDCS-ACmodelwithoutvotingandchapter6dis cussestrustin votersandthetrustworthinessofaDCS-ACsystemwherevoti ngisallowed. chapter7mentionssomefuturedirectionsofresearchandch apter8concludesthis work.

PAGE 17

CHAPTER2 DCSOVERVIEW 2.1 Introduction Intoday'shighly-networkedworkingenvironment,support forcollaboration andgroup-workhasbecomecritical.Theavailabilityoflow -costWideArea Networks(WANs)meansthatmembersofagroupcanbegeograph icallyscattered aroundthecountry(oreventheworld).Thereisagrowingnee dforecient architecturesandapplicationsthatfacilitatecollabora tionbetweensuchmembers. Asystemthatallowsuserstologonfromdierentlocations, toshareobjects,and toworkonthesameobjectwithothermembersofthegrouphasb ecomeessential insuchcases. TheDistributedConferencingSystem(DCS)seekstofulllt heserequirements andmanymore.Thesystemisbasedonarobustarchitecturean dprovides distributedleservices,accesscontrol,securecommunic ation,noticationand groupdecision-makingmechanisms.TheDCSwillprovidebas icdistributed collaborativeapplicationsliketexteditors,graphicsed itors,etc.,andcanalso supportthird-partyapplications.Thescalablearchitect urecansupportmultiple sitesandobjectscanbereplicatedtoensurefasteraccessa ndavailability.One ofthemajordesigncriteriaisfaulttolerance.Thesystemi sdesignedtohandle networkfailuresandsystemcrashesbyrestoringfrombacku psandcontacting othersitesforthemostup-to-dateinformation.Weachieve thisbyreplicating theobjectsacrossmultiplesitesandalsobymeansofbackup serversforeachsite whichcantakeoveriftheprimaryserverfails. 7

PAGE 18

8 2.2 Denitions BeforegettingintothedetailsofDCSandthevariousservic esprovided,we rstdenesometermsthatarerequiredtounderstandthearc hitecture: DCSinstance ThisisacollectivetermforoneormoreDCSsitesthatshare resources,communicateDCSspecicinformationwithandst oreinformation abouteachother.AnyuseridorCoGregisteredatonesiteisa ccessible fromallsitesinthatDCSinstance.AninstanceofDCSmaycov ermultiple administrativedomains. Site ThistermreferstotheDCSserver(s)locatedinasingleadmi nistrative domainthatprovideservicestotheusers.Sitesthatareapa rtofthesame DCSinstancecancommunicatewitheachother. Collaborativegroup(CoG) Thistermreferstoapersistentortransient groupconsistingofmembers,objects,applications,andaD CS-ACsystem (consistingofroles,objecttypes,allowablemember-role bindingsanddecision templates).ThemembersofaCoGworktogetherontheobjects anddecide grouppoliciesforthatCoG. User Thisisanentityinthesystemthatinitiatesactionand(int hecontext ofaccesscontrol)requeststoaccessobjects.Thistermusu allyreferstoa humanbeing. Member ThistermwhenusedinthecontextofaCoGreferstoauserwho isapartoftheCoGandhasbeengrantedrightsthatarenotgra ntedto non-members. Subject Thisrepresentsanactiveuserprocessthatisallowedtoper form someactionwithinthesystemonbehalfoftheuser. Object Thisisapassiveentityinthesystem.Userscanperformvari ous accessesonthem.Examplesofobjectsaredocuments,lesan dDCSsystem specictables. Application Thisisaprogramthattheuserlaunchesfromwithinthesyste m toworkontheobjects. Collaboration-ware Theseareapplicationsthataredesignedtosupport collaborativework.Thereforetheseapplicationswillhav eabetteraccess controlfeaturesthantheregularo-the-shelfapplicatio ns.

PAGE 19

9 DCS-awareapplications Theseareapplicationsthatarespecicallydesigned toworkwithintheDCS.Theseapplicationscanusethefeatur esofDCSlike eventnoticationornewaccesstyperegistration. Role Thisisanamedgroupofsubjects.Rolescanalsobeviewedasa collectionofjobfunctions.Aparticularsubjectcanbindt oanynumberof rolesbutatanypointoftime,thesubjectcanbeboundtoonly onerole.It mustbenotedthat role asusedhereisslightlydierentfrom role asusedin Role-basedaccesscontrolbecausethereisnonotionofarol e-hierarchyinthe DCSmodel. Objecttype Thisisanamedgroupofobjects.Aparticularobjectcanbelo ng toonlyoneobjecttype. 2.3 ATypicalDayatWork AtypicalinstanceofDCSconsistsofmanysitesandeachsite consistsofa primaryserverwithoneormorebackupservers(whichareran kedfrom1to n where n isthenumberofbackups)toensurehighavailability.Thepr imaryserver sendsperiodic heartbeats andupdatestothebackups[8].Ifthebackupsdonot gettheheartbeatfromtheprimaryforaxedamountoftime,t helowestranked backuptakesoverastheprimaryandinformstheothersitesi ntheinstance. Similarly,thesitesexchange heartbeats andifasitedoesnotrespond,theother sitescantakeoverthemanagementofobjectscontrolledbyt hefailedsite. Eachsitecontributesresources(likediskspace)totheins tanceandallobjects arepartiallyreplicatedtoprovidefaulttolerance.TheDC Sarchitectureisdivided intovariousmoduleseachofwhichprovidesadierentservi cetotheusers(section 2.4).AuserlogsintoaCoGthroughasiteandisboundtoarole (basedonthe user-rolebindingsmaintainedbytheAccessControlServic es).TheDistributed FileServicesprovidesauniformviewofthe DCSspace ,whichactuallyconsistsof objectslocatedondierentsites.Theusercanlaunchappli cationstoaccessthese objects,participateindecisionmakingprocessesorinter actwithothermembersof theCoG.Itmustbenotedthatsitearemanagedinthesamewaya sCoGs.That is,Oneachsite,thereisaCoGcorrespondingtothesitecont ainingallsubjects

PAGE 20

10 whojoinedtheDCSinstancefromthatsite;theycanformandi mplementtheir ownsitemanagementrules.Thefollowingsectionprovidesa briefdescriptionof thevariousservicesandtoolsavailableinDCS. 2.4 Services ThearchitectureofDCSv.2isshowningure2{1.Itisbasedo nvarious servicesavailableinmostnetworkeddomains(likelocall esystems,TCP/IP, cryptographicpackages,databasesystem,etc.).Sincewea reusingJava[9,10],the sitesneednotallrunthesameoperatingsystem.Abriefdesc riptionofthecore servicesisgivenbelow. 2.4.1 CoGManager (CM) Thisisthemoduleresponsibleformanagingthecollaborati vegroups(CoGs) [11].Thismoduleinstantiatestheothermodulesandthecli entsinteractwiththe otherservicesmainlythroughtheCM.Taskslikemergingtwo instancesofDCS orsitesorCoGs,andsplittinganinstance,asite,oraCoGis handledbythis module.TheCMinteractswiththesecuremessagingandthecr yptographiclayers duringuserlogin.Theuser'saccesscontrolrequestsarero utedthroughtheCM. TheCMalsoallowstheusertoimportandexportobjects,addn ewmembersand startsub-groups(sub-CoGs). 2.4.2 Notication Services (NTF) TheNTF[12]providesasynchronouseventnoticationtoreg isteredusers. Userscandeneneweventtypesandregistertobenotiedone vents.Subjects areautomaticallyregisteredfornoticationiftheyaream ongthevalidvoters onadecision.Thevariousservicesandapplicationsrunnin gintheinstanceraise eventsasandwhentheyoccurandtheNTFmaintainsaglobalan dlocaldatabase inwhichitstorestheuserstobenotiedoneacheventalongw iththedelivery method.

PAGE 21

11 ACS NTF MACE, A/V sharing, Whiteboard Applications Group Multicast AMCMDSS DBS SCS OS FS DFS A A DBMS JDBC UDP TCP RMI Crypto Secure Messaging Site Messaging Figure2{1:ArchitectureofDCS

PAGE 22

12 2.4.3 Database Services (DBS) TheDBS[13]makesuseofabackendDatabaseManagementSyste m(DBMS) [14]tomaintainthetablesofalltheDCSservicesandapplic ations.Mosttables arestoredaspartiallyreplicateddistributeddatabases. TheDBSusesgroup multicastandensureseventualconsistencyamongallmembe rsitesbyusingvector timestamps.SinceDBSusesJavaDatabaseConnectivity(JDB C)[15],wecanuse anybackendDBMSsystemlikeMySQL[16]orPostgreSQL[17]. 2.4.4 Decision Support Service (DSS) DecisionSupportSystem[18]isamodulethatfacilitatesre solvingissuesbya groupofuserswhohaveajointresponsibilitytosuchdecisi ons.Votingisoneofthe toolsofDSSwhichisdesignedtobearexibleandfriendlysys temthatallowsusers toinitiate,participateinandterminatedecisionswithin thecontextofaCoG.It provideson-linevotingandhasautomatedvotecollectionm echanisms.Itallows memberswhoarecurrentlyo-linetobevotersinadecisionp rocess.Theinitiator ofthevotecansettimeconstraintsandspecifyvotingparam eters,voters,reporting stylesandreportrecipients. Thisservicetakesintoaccounttheuser'srole,weightassi gnedtothevoteand accessrights,etc.Ithasseveralfeatureslikereminders, requestforstatus,change ofvote,shortcircuitevaluation,withdrawalandterminat ionofactivevotes,which addmorerexibilitytothedecisionprocess.Italsoallowso thermodulesofDCSto maketheserequests. Themodulesupportsdierentvotingmethodslikemajority, plurality,and ranking.Userscansavetheirrequirementsastemplatestha tcanbereusedinthe futurebyanyonewhohastheaccessrightstodoso. 2.4.5 Access Control Services (ACS) TheACS[19],asthenamesuggests,controlsaccessto(CoG-s pecicor instance-specic)objects.Itmakesuseofdecisiontempla tesoftheDSStoprovide

PAGE 23

13 groupdecision-basedaccesscontrol.Thisputsthecontrol oftheCoGinthehands ofthemembers.TheACSstoresitstablesinadatabasethroug htheDBS.The ACSallowsapplicationstoregisternewaccesstypes.Thisa llowsmorene-grain accesscontroliftheapplicationsupportsit. TheACSinteractswithalltheothervemodulesandprovides various servicestotheusers.TheDCSarchitecturerequirestheACS toallowdecisions tobemadeonaccesscontrolrequestsatthesourcesiteitsel f.Thiscoupledwith thedecisiontemplatesmakestheACSaninterestingstudyin itself.Themodel usedhereisnotspecictoDCSandcanbeusedinanydistribut edsystemthat supportsgroupdecision-makingmechanisms. 2.4.6 Secure Communications Services (SCS) TheSecureCommunicationServices[20]ensurestheconden tiality,authenticityandintegrityofallmessagespassedbetweensitesandcl ients.Toenforcethese importantsecurityproperties,itisnecessarytoestablis htheidentityoftheentities ofthesystem.Theentitiesofthesystemareusers,hosts,an dservers.Theidenticationoftheentitiesshouldbedonereliably,thatis,its houldbeauthenticated. DCSposesagreaterchallengesinceentitiescommunicateth roughmessagesand hencealltheentitiesmustestablishtheiridentitiesandm aintaincondentiality.In DCS,identityisrstestablishedusingstrongauthenticat ionandper-connection symmetriccryptographyprovidescondentialityandinteg rity.TheSCSisalso responsibleforcreationandmaintenanceofkeysandcerti catesforsitesandusers. 2.4.7 DistributedFileServices (DFS) TheDistributedFileServices[21]providesaDCS-specicv iewoftheobjects locatedatvarioussites.Itallowsconcurrentaccessofle susingaversioning schemewithimmutablesharedlesandisdesignedtoprovide reasonableservice inthecaseofsitecrashes.EachCoGisrepresentedbyadirec toryin DCS-space andsub-CoGsaresimplysub-directoriesunderthedirector ycorrespondingtothe

PAGE 24

14 parentCoG.TheDFScreatesandmaintainsmultiplecopiesof allobjects,thereby ensuringhighavailability. 2.4.8 ApplicationManager (AM) TheApplicationManagerisresponsibleforregisteringand invokingapplicationsthatareavailableforeachCoG.Theseapplicationsco uldbeDCS-aware(like MACE[22])orDCS-unaware.TheAMmaintainsalistofapplica tionsavailablefor aparticularCoG,anddependingontheaccessrightsoftheus er,itmakesthose availabletotheusers. 2.4.9 Tools TheDCSframeworkprovidesafewbasictoolsforcollaborati on.Theseinclude instantmessaging(Gossip),concurrenttext(MACE)andgra phics(Ensemble) editors. Gossip Thisisasimpleinstantmessagingapplicationthatisapart ofthe clientGUI.Itallowstheusertobeintouchwithhis/hercoll aborators. MACE MACE[22]standsforMotherofAllConcurrentEditorsandis averypowerfulconcurrenttexteditor.Inadditiontoregul artexteditor features,MACEallowsuserstolockvariouspartsoftheles andshareviews. MACEprovidesaveryne-grained(byte-level)lockingmech anismandthe usercansettheviewrightsforothers,i.e.,theotherusers canseeeverykey strokeorreceiveupdatesonlywhenthewritercommitsthech anges.This allowsotherusersto\lookovertheshoulder"ofthewriter( usefulinpair programmingamongotherareas). Ensemble Ensembleisaconcurrentgraphicseditorsthatprovidesobj ectlockingandspecicuserpointerview.Multipleuserscanwo rkonthesame gureandeachusercanlockoneormoreobjectsandsharecurs or,allowing otheruserstoseeexactlywhatisgoingon. 2.5 InteractionWithOtherServices SinceweareprimarilyconcernedwiththeACS,whichimpleme ntstheDCSACmodel,letuslookatACS'interactionswiththeotherserv ices.Asmentioned

PAGE 25

15 earlier,ACSinteractswithallthecoreservices.Outofthe se,DBSandDSS providevitalservicesrequiredforACS. 2.5.1 InteractionWithDBS AllACSinformationaboutaCoGarestoredasrelationaldata basetablesthat arereplicatedacrossallsitesinterestedintheCoGbyDBS. WhenanewCoGis created,therelevantACStableshavetobecreatedontheloc alsite.Whenever asitewantstoparticipateinaCoG,itobtainsadumpoftheAC Stablesfrom asitethatisalreadyintheCoGandcopiesitontothelocalda tabase.Any databasequerycanbehandledbytheDBMSatthelocalsitebut updateshaveto beforwardedtothesitethat\owns"theentryandthenmulticasttoothersites. 2.5.2 InteractionWithCM TheCMcontrolstheentireconferenceandinstantiatestheo bjectsthat providetheservicesincludingACS.Moreover,mostuserreq uestsarepassedonto theACSthroughtheCM.MostCM-originatedactionshavetobe checkedthrough theACSforaccessprivileges.Forexample,ifauserwantsto importanewle,the CMwillhavetocheckwiththeACSbeforeproceedingwiththei mport. 2.5.3 InteractionWithDSS TheDSShandlesthedecision-makingprocessandistherefor ecloselytiedto theACS.Ifarequestrequiresavote,theDSShastobeinvoked andthevoting processinitiated.TheACSmustbeabletocheckthestatusof aparticularvote. Whenavoteiscompleted,theDSSshouldnotifytheACS.Simil arly,theACS mustbeabletoreportalistofactivevotestotheDSSiftheDS Sdecidestodelete obsoletevotes.Actionslikedeningnewtemplatesandmodi fyingexistingones requireacheckbytheACS. 2.6 Summary Thecoreservicesdescribedhereprovideaframeworkfordis tributedcollaboration.Thethreetoolsmentionedarewhatweconsidermini malapplications

PAGE 26

16 requiredbycollaboratingusers.TheApplicationManagera llowsuserstoexecute otherapplicationsfromwithintheDCSframework.Aswillbe comeclearinthe nextchapter,DSSisrequiredbytheDCS-ACmodelsinceithan dlesallvoting relatedissues.

PAGE 27

CHAPTER3 BACKGROUND 3.1 Introduction Thischaptersurveyssomeoftheworkinaccesscontrolandtr ustinvoters thatisrelevanttotheDistributedConferencingService-A ccessControl(DCS-AC) model. 3.2 AccessControl Protectionofobjectsiscomplexbecausethenumberofacces spointsmaybe large,theremaybenocentralauthoritythroughwhichallac cessrequestspass, andthekindofaccessisnotsimplylimitedtoread,write,or execute.Accordingto Preeger[23],thereareseveralcomplementarygoalsinsuch amechanism. Checkeveryaccess .Wemaywanttorevokeauser'sprivilegetoaccessan object.Ifwehavepreviouslyauthorizedtheusertoaccesst heobject,wedo notnecessarilymeantheusershouldretainindeniteacces stotheobject. Allowleastprivilege .Asubjectshouldhaveaccesstothesmallestnumber ofobjectsnecessarytoperformsometask.Notallowingunne cessaryaccess toobjectsguardsagainstsecurityweaknessesifapartofth eprotection mechanismshouldfail. Verifyacceptableusage .Thenaldecisiononanaccessrequestisayes-no decision.Ofmoreinterestischeckingthattheactivitytob eperformedonan objectisappropriate. AccesscontrolpoliciesarebroadlyclassiedasMandatory AccessControl (MAC)andDiscretionaryAccessControl(DAC).MACmeanstha taccesscontrol policydecisionsaremadebeyondthecontroloftheindividu alownerofanobject. Acentralauthoritydetermineswhatinformationistobeacc essiblebywhom,and theusercannotchangeaccessrights[23].Aclassicexample ofMACisinmilitary 17

PAGE 28

18 securitywheretheownerofa\top-secret"objectcannotdec idewhohastop-secret clearancenorcantheownerchangetheclassicationoftheo bjectto\secret". ExamplesofmodelsthatenforceMACincludeBell-LaPadulaC ondentiality model[24]andBibaIntegrityModel[25].DAContheotherhan d,allowsthe ownerofanobjectoranyoneelsewhoisauthorizedtocontrol accesstotheobject tospecifywhohaswhataccesstotheobject.Theaccessright sinaDACscheme canchangedynamically[23].Oneofthemaindierencesbetw eenDACandMAC isthefactthatMACisalsoconcernedwiththerowofinformat ion[26]. Inthiswork,wearemainlyconcernedwithDACsincewewantth eusersto beabletodecidetheirownaccesscontrolpolicieswithouta nycentralauthority. Inthefollowingsectionswelookatvariousprotectionmech anisms.Firstwewill considertheAccessMatrixmodel.Wealsodescribecertainm odicationslike AccessControlListsandCapabilitylistsalongwiththeGra ham-Denningand Harrison-Ruzzo-Ullmanmodels,whichareallDACmodels.Ne xtwewillreview rolebasedaccesscontrol,andtheDistributedCompartment Modelforresource managementandaccesscontrolproposedbyStevenGreenwald .Finally,wewill lookatrecentworkonaccesscontrolforcollaborativeenvi ronments. 3.3 AccessMatrixModels Accesscontrolmatrices arethemostpopularmeansofmodelinganaccess controlsystem.Anaccesscontrolsystemhasagroupofusers ,objectsandaccess rightsforthoseusersonthoseobjects.TheHRU[27]andGrah am-Denning[2] modelsareearlyexamplesofsuchmodels.Suchsystemshavea setofcommands thattestthepresenceofvariousrightsinthematrixandthe nexecuteasequence ofoperations.Mostmodernsystemsuseavariationoftheacc esscontrolmatrix likeaccesscontrollistsorcapabilitylists.Accessright sleakageisaninteresting propertyofaccesscontrolsystems.Oneofthemanymeansofa nalyzingamodelis totrytoclassifytheleakageproblemforthatmodel.

PAGE 29

19 Table3{1:PrimitiveOperationsinHRUmodel enter r into( X s ;X o ) delete r from( X s ;X o ) createsubject X s createobject X o destroysubject X s destroyobject X o 3.3.1 HRUModel Harrison,RuzzoandUllmanproposedamodelin1976thatispo pularly referredtoastheHRUmodel[27].AHRU protectionsystem consistsofastatic, nitesetofrights R ,andastatic,nitesetofcommands, C .Therearesix primitiveoperationsdenedwhicharegiveninFigure3{1.A conguration ofa protectionsystemisatriple( S;O;P ),where S isthesetofsubjects, O istheset ofobjects, S O ,and P isarightsmatrix,witharowforeachsubjectanda columnforeachobject. P [ s;o ]( R )givestherightstotheobject o possessedby thesubject s .Theformaldenitionofthemodelisasfollows: Denition: A protectionsystem consistsofthefollowingparts: 1.anitesetof rights;R 2.aniteset C of commands oftheform: command ( X 1 ;X 2 ;:::;X k ) if ( r 1 2 ( X s 1 ;X o 1 )) ^ ::: ^ ( r m 2 ( X sm ;X om )) then op 1 :::op n end Hereeachsubjectorobject X si or X oi isoneoftheparameters X j andeach operation op i isoneofthe primitiveoperations giveninTable3{1. AccessrightLeakWhilewecannotexpectausefulsystemtobesafeinthestrict estsense,the minimumtolerablesituationisthattheusershouldbeablet odecidewhethera

PAGE 30

20 givencongurationcouldleadtosomeotherusergettingasp ecicright,i.e.,if theright leaks tootherusers[27].Needlesstosay,therearesomeuserswho mwe trustandinfactexpecttohavetheright.Weremovetherowsc orrespondingto thoseusersandtrytondoutiftherightleakswhensomesequ enceofcommands isexecuted.Theformaldenitionofthesafetyquestionfor accesscontrolsystems isgivenbelow:Denition Givenaprotectionsystem,wesayasequenceofcommands 1 ; 2 ;:::; n leaksaright fromastartingstateQ ifthecommandswhenrunon Q (insequence),canexecuteaprimitiveoperationthatallowssome usertheright that wasnotallowed Q Inotherwords,asystem leaksaright ifandonlyifitispossibleforan unintendedsubjecttogettheright onanobject o bytheexecutionofasequence ofcommands.Theauthorshaveprovedthatthesafetyquestio n(alsocalledaccess rightleakageproblem)isgenerallyundecidablefortheHRU model.Itisinteresting tonotethatifweenforcethemono-operationrestriction,i .e.,eachcommandcan executeonlyoneoftheprimitivecommands,thenthesafetyq uestionforsucha systemisNP-complete.However,mostusefulHRUsystemscan notsatisfythe mono-operationrequirement. TheTypedAccessMatrix(TAM)model[28],[29]addsstrongty pingtothe HRUmodel.TheaccessrightsproblemforthegenericTAMmode lhasbeen proventobeundecidablebuttherearecertainrestrictedve rsionsofTAMforwhich theproblemhasbeenproventobeNP-Hard. 3.3.2 TypedAccessMatrix RaviSandhuandothershaveworkedonmodifyingtheHRUmodel tomake thesafetyproblemdecidablewhileatthesametimemaximizi ngtheexpressing power[30].TheTypedAccessMatrix(TAM)[28]denedbySand hucombines strongsafetypropertiesforpropagationofaccessrightso fSchematicProtection

PAGE 31

21 Table3{2:PrimitiveOperationsinTAMmodel enter r into [ X s ;X o ] delete r from [ X s ;X o ] createsubject X s oftype t s deletesubject X s createobject X o oftype t o deleteobject X o Model[31]withthenaturalexpressivepoweroftheHRUmodel .TAMisobtained byincorporatingstrongtypingintotheHRUmodel[29].Itis importantto understandthatthetypesandrightsarespeciedaspartoft hesystemdenition. Thesystemadministratorspeciesthefollowingsetsforth ispurpose: anitesetofaccessrightsdenotedby R ,and anitesetofobjecttypesdenotedby T The protectionstate isaTAMsystemisgivenbythefour-tuple( OBJ SUB t AM )interpretedasfollows: OBJ isthesetofobjects. SUB isthesetofsubjects, SUB OBJ t : OBJ T ,isthe typefunction whichgivesthetypeofeveryobject. AM istheaccessmatrix.Wehave AM [ S;O ] R where S isasubjectand O isanobject. TheprotectionstateofthesystemischangedbymeansofTAMc ommands.Each TAMcommandhasthefollowingformat: command ( X 1 : t 1 ;X 2 : t 2 ;:::;X k : t k ) if r 1 2 [ X s 1 ;X o 1 ] ^ r 2 2 [ X s 2 ;X o 2 ] ^^ r m 2 [ X s m ;X o m ] then op 1 ; op 2 ; ::: ; op n end Here isthenameofthecommand; X i areformalparameterswhosetypesare t i ; r i arerights.Each op i isoneoftheprimitiveoperationslistedintable3{2.

PAGE 32

22 Therights,typesandcommandsdenethesystemscheme.Thes chemecan bemodiedonlybythesystemadministrator,whoisnotconsi deredtobeapart ofthesystem.Thetypeofanobjectisxedandcannotbechang edwithinthe system.SandhuhasprovedthatTAMhasconsiderableexpress ivepower. SafetyprobleminTAMTheaccessrightsleakageproblemforthegeneralTAMmodeli sundecidable (refertotheoriginalpaper[29]forproof).Theauthorden esafewrestrictions onTAMthatallowustomaketheproblemdecidable.ATAMsyste mthatdoes nothaveanycommandthatdeletesarightordestroysasubjec torobjectiscalled MonotonicTAM.Insuchasystem, S O and P [ s;o ]areallmonotonicallynondecreasing.Inagivencommand ,wesaythatatype t i isa childtype inthat commandifoneofthefollowingprimitiveoperations createsubject X i oftype t i or createobject X i oftype t i occursinthebodyof .Thetype t j issaid tobea parenttype in ifoneoftheparametersof isoftype t j and t j isnota childtypein .The creationgraph ofanTAMschemeisadirectedgraphwith vertexset T andanedgefrom u to v ifandonlyifthereisacommandinwhich u isaparenttypeand v isachildtype.ATAMschemeis acyclic ifandonlyif itscreationgraphisacyclic.ATernaryTAMisidenticaltoT AMexceptthatall commandsarelimitedtoamaximumofthreeparameters.Given theseproperties, Sandhuhasprovedthefollowingresults: 1.GenericMTAMisundecidable.2.AcyclicMTAMisNP-Hard.3.ThesafetyquestionforacyclicternaryMTAMisdecidable inpolynomial timeinthesizeoftheinitialaccessmatrix.

PAGE 33

23 3.3.3 AccessControlinUNIXOperatingSystem TheUNIXoperatingsystemwasdevelopedatBellLaboratorie sinthelate 1960s.Itevolvedina\friendly"environment,onsystemsth atencouragedusers tosharetheirles[32].However,UNIXisbydesignaveryrob ustsystem.The followingisabriefdiscussionofthebasicprinciplesinUN IXaccesscontrol. FilesarecentraltoUNIXinwaysthatarenottrueforotherop erating systems.Commandsareexecutablelesinspecicdirectori eslike /bin /usr/bin etc.Systemprivilegesandpermissionsarecontrolledinal argepartviaaccessto les[33].Accesstolesisorganizedaroundleownershipa ndprotection. Eachlehasauserownerandagroupowner.UNIXsupportsthre etypesof leaccess:read( r ),write( w ),andexecute( x ).Adierentsetofaccessrightscan besetforuserowner,groupmembersandothers.Forexample, theaccessright rwxr xr meansthattheuserownercanread,writeandexecutethele, membersofthegroupownercanreadandexecutethelebutall otherscanonly readthele.Thecommandthatisusedtoaltertheaccessmode is chmod Thereareafewotherdenedlemodes,namely, t (Stickybit,keepexecutable inmemoryafterexit), s (SetprocessuserIDorgroupIDonexecution),and l (set mandatorylelockingonreads/writes).Filesthatbeginwi thaperiodarehidden lesandarenotlistedby ls commandunlessusedwiththe a option.The l optionof ls commandliststhelesalongwiththemodesandownersofthe les. Thesetofcommandsthatareusedtomodifytheaccessrightso flesare: chmod Specifytheprotectionmodesforles. umask Specifythedefaultmodefornewlycreatedles. chown Changetheuserownerofale. chgrp Changethegroupownerofale.

PAGE 34

24 SomevariantsofUNIX,likeAIXandHP-UXprovideaccesscont rollistswhich oerafurtherrenementtothestandardUNIXlepermission scapabilities.These ACLsconsistofthreeparts: 1. Attributes SpeciesanyspecialattributeslikeSETUIDandSETGID. 2. Basepermissions ThesecorrespondexactlytotheUNIXlemodesand specifyaccessrightsforowner,groupandothers. 3. Extendedpermissions Theseareaccessinformationspeciedbyuserand groupname. ACLsthatspecifyausernameandgroupareusefulforaccount ingpurposes.They arealsousefulifyouaddauseronatemporarybasis[33]. UNIXwastherstmajornetworkoperatingsystem.Itprovide svarious serviceslikeNIS(NetworkInformationServices)andNFS(N etworkFileSystem) thathelpinadministeringanetwork.UsingNIS,userscanlo gontoanymachine onthenetworkthatbelongstothesameNISDomain.Inanetwor kwithtwenty machines,theadministratorhastoaddthenewuseronjuston emachineandthat usercanlogontoanyoneofthesetwentymachines.Inorderto provideauniform directorystructurewhenauserlogsin,administratorsmou ntlesystemsoverthe network.Usually,theuser'shomedirectoriesaremountedu singNFS.Thiswaythe user'slesareavailabletohim/heronanymachineinthenet work.Theadvantage withthisarrangementisthatcontrollinglepermissionsi sthesameasdescribed earlier. Usersauthenticatethemselvestothesystembyprovidingau sernameand password.Itisveryimportantforuserstoprotecttheirpas swordsbecauseifthe passwordiscompromised,thenallloginsmaybecompromised [32].Passwords andlepermissionsaretwobasicwaysofpreventingsecurit yproblemsinUNIX. Passwordspreventbadguysfromgettingonthesysteminthe rstplaceand properlepermissionspreventnormalusersfromdoingthin gstheyarenot

PAGE 35

25 supposedto[33].Thereareonlythreeaccesstypesandusers cannotdenetheir ownaccesstypes.Moreover,theownerofalehasfullrights todoanythingwith thele.Inmanyorganizations,thelesarenot\owned"byth eusersbutbythe organizationitself. 3.4 Role-BasedAccessControl(RBAC) Role-BasedAccessControl(RBAC)[34,35,36,37,38]isamod elthatis gainingpopularity.TheprincipalmotivationsbehindRBAC aretheabilityto articulateandtoenforceenterprise-specicsecuritypol iciesandtostreamlinethe typicallyburdensomeprocessofsecuritymanagement. Inmanyorganizations,theendusersdonot\own"theinforma tionforwhich theyareallowedaccess.Thecorporationistheactual\owne r"ofsystemobjects aswellastheprogramsthatprocessitandcontrolisoftenba sedonemployee functionsratherthandataownership. InRBAC,usersdonothavediscretionaryaccesstoenterpris eobjects.Instead, accesspermissionsareassociatedwithrolesandusersarea ssociatedwithroles.A rolebasedaccesscontrolpolicybasesaccesscontroldecis ionsontherolesauseris allowedtotakeonwithinanorganization.Thedeterminatio nofrolemembership andtheallocationoftransactionstoaroleisincompliance withorganizationspecicprotectionguidelinesderivedfromexistinglaws, ethics,regulations,or generallyacceptedpractices.WithRBAC,usersarenotgran tedpermissionto performoperationsonanindividualbasis,butoperationsa reassociatedwith roles.Thishastheadvantageofsimplifyingtheunderstand ingandmanagementof privileges. Systemadministratorscontrolaccessatalevelofabstract ionthatisnaturalto thewayenterprisestypicallyconductbusiness.RBACaddre ssessecurityprimarily forapplication-levelsystems,asopposedtogeneralpurpo seoperatingsystems.

PAGE 36

26 RBACenforcesthefollowingrulesonroleauthorization,ro leallocation,and operationexecution.RBACconstraintsareusedtoexpresss eparationofduty. 1.Rolehierarchy Ifasubjectisauthorizedtoaccessaroleandthatrole containsanotherrole,thenthesubjectisalsoallowedtoac cessthecontained role. 2.Staticseparationofduty Auserisauthorizedasamemberofaroleonlyif thatroleisnotmutuallyexclusivewithanyoftheotherrole sforwhichthe useralreadypossessesmembership. 3.Cardinality Thecapacityofarolecannotbeexceededbytheadditionof anotherrolemember. 4.Roleauthorization Asubjectcanneverhaveanactiverolethatisnot authorizedforthatsubject. 5.Roleexecution Asubjectcanexecuteanoperationonlyifthesubjectis actingwithinanactiverole. 6.Dynamicseparationofduty Asubjectcanbecomeactiveinanewroleonlyif theproposedroleisnotmutuallyexclusivewithanyofthero lesinwhichthe subjectiscurrentlyactive. 7.Operationauthorization Asubjectcanexecuteanoperationonlyifthe operationisauthorizedfortheroleinwhichthesubjectisc urrentlyactive. 8.Objectaccessauthorization Asubjectcanaccessanobjectonlyiftheroleis partofthesubject'scurrentactiveroleset,theroleisall owedtoperformthe operationandtheoperationtoaccesstheobjectisauthoriz ed. 3.5 DistributedCompartmentModel TheDistributedCompartmentModel[39,3]wasproposedbySt evenGreenwaldasasolutiontomanagementofsystemresourcesandacce sscontrolina distributedcomputingenvironment.Themodelconsistsoft woparts,(i) DistributedHandles ,ameansforuseridenticationandaccesscontroland(ii) DistributedCompartments ,amethodforallowinguserstomanageresourceswithin adistributedsystemacrosscomputersystemboundarieswit hameasureofindependencefromanysystemadministrations[39].Thedistrib utedhandleseliminate

PAGE 37

27 groupwareapplicationuserIDsasameansofidenticationa ndaccesscontrol. Auserjoiningagroupwaresessionisqueriedforahandletha tisuniquetothat applicationandisthenveriedbyagroupwaresecuritymana ger. Underthismethod,anindividualuserwouldrstgainaccess toaparticular computersysteminthedistributedsystembyhavingavalidu serIDandpassword. Theuserwouldthenneedavaliddistributedhandleandwould thenneedtobe validatedbythegroupware'saccesscontrolsecurityinord ertobeallowedaccessto theapplication. Themajoradvantageofthisapproachisthatsecuritydepend enciesarereduced.Moreover,thehandlescanbemoredescriptivethanus erIDs,forexample \Thirdprogrammer"insteadof\av0".Multiplehandlescanb epermittedforthe sameuserandmanyuserscansharethesamehandle.Distribut edcompartment (alsocalleddiscom)isthedesignatedplatformforaccessc ontrolandadministrationofdistributedhandles. Adiscomisalogicalgroupofobjectsthatisconceptuallysi milartoastandardhierarchicaldirectorystructurebutdoesnotnecessa rilyresideinasingle computer.Theusersofdiscomsgainaccessviadistributedh andles.Arootdiscom iscalledan empirediscom .Eachdiscommusthaveatleastonesubjectcalled governor .Governorshavethemaximumprivilegesforthediscomtheyg overn. Thereare24basicoperationscalled initialprivileges .Theyincludeoperations thatcreate,destroy,ormodifyobjects,create,delete,me rge,split,ormodifychild discomsandempire,createorrescindprivilege,createorr emovegovernorships, subjectsorresources,etc.Thiscombinationofsubjects,o bjectsandprivileges, makesitpossibletocreateasystemsimilartoanaccesscont rolmatrix. TheDistributedCompartmentModelhasasetofaxiomsandpro pertiessome ofwhichare:

PAGE 38

28 DivineRightAxiom Asubjectcancreateanempirediscomonlyifgiventhat privilegebytheadministrators. CreatorProperty Thecreatorofadiscomautomaticallybecomesagovernor ofthatdiscom. GovernmentProperty Thegovernorofadiscommaygrantandrevoke privilegestonon-governorsubjectsofthatdiscom. Novaproperty Anon-governorsubjectmayaccessadescendantdiscomonly ifmadeamemberofthatdiscombyagovernorofanancestordis com. CordonProperty Discomsmayneverintersectwithotherdiscoms. DemesneProperty Thegovernorofadiscomalwayshasunrestrictedaccessto descendantdiscoms. CeilingProperty Asubjectmaynotaccessanancestordiscomwithoutbeing asubjectofthatdiscom. Adistributedcompartmentisactuallyagroupwareapplicat ion,withaccesstothe discomsdeterminedbydistributedhandles.Managementofd iscomsisnotdoneby thelocalsystemadministratorsbutbytheindividualusers whoaregovernorsof empirediscoms. 3.6 AccessControlforCollaborativeEnvironments BasedontheworkbyGreif[40]andEllis[41],BullockandBen ford[42]have identiedfourbasicrequirementsforcollaborativeacces smodels: Themechanismmustbesimple. Themechanismshouldbeunobtrusivetousers. Itshouldbeeasytoinspectandchangeaccessrights. Theeectsofaccesscontrolsshouldbeunderstood,andthec onsequencesof anychangesshouldbeclear. Haakeetal.[43]\...foundthatend-usersinordertoconduc tcooperativework insharedworkspacesystemhavetobeableto(1)creategroup sdynamically

PAGE 39

29 withoutpriorplanningofasystemadministrator,(2)emplo ydierentformsof groupformation,and(3)controlaccessrightstotheirwork spaces."Manycurrent systemslacksucientsupportfortheserequirements. ShenandDewan[44]haveextendedthetraditionalaccessmat rixmodelfor groupwarewithmorethan50basicaccessrightstohandlethe variousoperations requiredforcollaborationandinheritancebasedonrightg roupings.Theyalso supportthenotionof negativerights toallowexplicitdenialofrights. ParkandHwangin[45]tailorthegenericarchitectureforco ntrolledPeerto-Peer(P2P)computingenvironmentstosupportRBAC.Forc ollaborative enterpriseinsuchanenvironment,theyidentifythreedie rentpolicies:enterprise, communityandpeer.Acommunitypolicydenesthecommunity 'sUser-Role Assignment(URA),Permission-RoleAssignment(PRA),cons traintsandrolehierarchy.Anenterprisepolicydenestheenterprise'sUR A,PRA,constraints, role-hierarchyandroleontology(anequivalencerelation betweenrolesindierent communities[46]).Eachpeerdenesitsownpeerpolicyincl udingthepeer'sPRA andconstraints.Theenterprisepolicyisenforcedbyacent ralizedmechanismthat appliestoallcommunitiesinthatenterprise,whileacommu nitypolicyisenforced byacentralizedmechanismwithinthecommunity.Thesetwom echanismsare basedonthebrokeredP2Pmodel.Ifaconrictoccursbetweenp olicies,enterprise policiesaresuperiortocommunitypolicies,whicharesupe riortopeerpolicies unlessspecicpolicypriorityisdened. JaegerandPrakash[47]deneadiscretionaryaccesscontro l(DAC)model forspecifyingtheaccessrightsavailabletoamobileagent whichenablesthe readerandwriterinamobileagentcomputationtorexiblyco ntrolaccessto systemobjects.TheyalsospecifytherequirementsofRBACm odelsnecessaryto implementtheDACmodel.InthistypeofRBACmodel,systemad ministrators denerolesforusers(asinregularRBAC)butcanalsodenea modelthatwill

PAGE 40

30 enableuserstolimittheaccessrightsoftheirownprocesse s.First,systemadmins specifytheobjecttypesthatcanbeusedtospecifyoperatio naccessrights.Also, systemadminsspecifytheuserswhoareauthorizedtolimitt heirownrights dynamically. 3.7 TrustandVoting WhilesignicantworkhasbeendoneintheeldsofPolitical Science,Psychology,and,Ethics[48,49],\mostoftheworkconcerningtrust incomputerscience havebeenconcentratedintheareaofsecurity...mainlyint heformofformal logicstoanalyzecryptographicprotocolsfordesignrawsa ndcorrectness."[50]. OneofthemostpopulardenitionsoftrustisgivenbyDeutsc h[51]. (a)anindividualisconfrontedwithanambiguouspath,apat hthat canleadtoaneventperceivedtobebenecialortoaneventpe rceived tobeharmful;(b)heperceivesthattheoccurrenceofthesee vents iscontingentonthebehaviorofanotherperson;and(c)hepe rceives thestrengthofaharmfuleventtobegreaterthanthestrengt hofa benecialevent.Ifhechoosestotakeanambiguouspathwith such properties,hemakesatrustingchoice;elsehemakesadistr ustful choice. Gambetta[52]hasdenedtrustas\aparticularlevelofthes ubjectiveprobability withwhichanagentassessesthatanotheragentorgroupofag entswillperform aparticularaction,bothbeforehecanmonitorsuchaction( orindependently ofhiscapacityevertobeabletomonitorit)andinacontexti nwhichitaects hisownaction."Thisdenitionhasbeenwidelyacceptedbyc omputerscientists Gambettaintroducedtheconceptofusingvaluesfortrustan dalsodefendedthe existenceofcompetitionamongcooperatingagents.Trusti scloselyrelatedto reputation[53].Abdul-RahmanandHalies[50]denereputa tionasanexpectation aboutanindividual'sbehaviorbasedoninformationabouto robservationsof itspastbehavior.Inonlinecommunities,whereanindividu almayhavevery lessinformationtodeterminethetrustworthinessofother s,theirreputation

PAGE 41

31 informationistypicallyusedtodeterminetheextenttowhi chtheycanbetrusted. Anindividualwhoismorereputedisgenerallyconsideredto bemoretrustworthy. Reputationcanbedeterminedinseveralways.Forexample,a personmayeither relyonhisdirectexperiences,orrelyontheexperiencesof otherpeople,ora combinationofbothtodeterminethereputationofanotherp erson. Asmentionedearlier,workconcerningtrustincomputersci encehasbeen primarilyfocusedoncryptographylikein[54]andworkinvo tinghasbedominated byelectronicvoting[55]wheretheemphasisisonauthentic ationandguaranteeing thatthevotecountedasvoted.Marsh'smodel[56],asfarasw eknow,isoneofthe fewattemptstoformalizetrustbasedontherealworldsocia lpropertiesoftrust. 3.8 Summary TheHRUmodelisaverypowerfulmodelintermsofexpressivep ower. However,itisveryprimitiveinitsconstructionandhasnor oles,objecttypesor otherabstractions.Thereforethematrixcanbeverylarge( andsparse).Itisnot easytoimplementthismodelinadistributedsystem. TheTAMmodeltakesahugestepforwardwiththeadditionofty ping. However,thesetoftypesisstaticandtherearenooperation sdenedinthesystem tochangethetypeofanobjectorsubject.Aswewillshowinth elatersections, makingitpossiblefortheuserstodenetheirowntypesandc hangethetypes allowsustoimplementmanyimportantandinterestingsyste mpolicies. RBACprovidesameansofnaminganddescribingrelationship sbetween individualsandrights.SomeformofRBACisusedincommerci alsystemstoday andsomeattemptshavebeenmadetoformalizethemodel(refe r[36]).Oneofthe majorareasinwhichtheDCSmodelscoresoverRBACisgroupde cisions.Another restrictionistheabsenceofsomemechanismthatallowsde ningone-to-one relationshipsbetweensubjectsandobjects.Forinstance, considertheownership relation.PureRBACcanhandlethecasewhereeachobjecthas onlyoneowner,

PAGE 42

32 however,ifsomeobjectsinthesystemhaveasmallsubsetofu sersasitsowner(s), itisimpracticaltodenenewrolessuchas ownerofobject1 (wewillneedas manysuch\ownerroles"asthereareobjects). OnemajordisadvantagewiththeDiscommodelisthatuserswi llhavetohave aseparatehandleforeachapplicationtheyuse.Thismeanst hattheywillhave toremembernotjusttheiruserIDandpasswordbutthehandle andpasswordfor eachapplication.Itwouldhavebeenpreferabletoavoidsuc hmultiple\logins". Sincemanyuserscansharehandles,thisreducesaccountabi lity.TheDiscommodel practicesatypeofmonarchyinwhichthegovernorshaveabso lutepowerwhereas ademocraticformofgovernmentwillbemorepracticalinthe longrun.The Discommodelisreallyconcernedwithresourcemanagementi nhierarchicalgroups distributedovermultipledomains.TheDCSmodelisconcern edwithauthorization issuesandthesetwomodelscanbeusedtogether,providinga secure,rexible system. Alltheabovemodelsrequireasystemadministratortohandl ethechangesin thesystem.Incorporatinggroupvotingmechanismsallowth euserstodecideand implementthegrouppolicies.Thisisoneofthemainfeature softheDCSmodel. TheJaegerandPrakashmodelallowssystemadministratorst ospecifysome DACfeaturesandwhocanusethem.Theuserswiththeprivileg ecancontrol accesstotheirprocessesbutthisisstillverylimitedDACa nddoesnotallow thegroupstodecidetheirownpolicies(theycandosoonlyfo rthoseobjects thesystemadminsallow).TheRBACschemeforP2Penvironmen tsdescribed abovereliesextensivelyonservercontrolleddecisionsan ddoesnotsupportgroup decisions.Itdoeshoweversupportcommunity-levelautono mywhichallowspolicy decisiontobemadeo-lineandchangesareenforcedbysomeo newithadmin-level privileges.

PAGE 43

CHAPTER4 THEDCS-ACMODEL 4.1 Introduction Inthischapter,wewillintroduceandformallyspecifytheD istributedConferencingServices-AccessControl(DCS-AC).Wewillalsod iscusstheconstraints andrulesthatareimposedonanysystemthatimplementsthis model.Finally,we willdiscusssomeofthekeyfeaturesofthemodelandshowthe DCS-ACsolution tothesoftwareproblemmentionedinsection1.2. 4.2 TheDCS-ACModel Theaccesscontrolmatrixisoftenverybigandsparse.RolebasedAccess Control(RBAC)groupssubjectsinto roles andobjectsinto objecttypes ,thereby shrinkingthematrix.Inthesesystems,eachcellinthematr ixcorrespondtothe setofrightsthecorrespondingrole(identiedbytherow)h adwithrespecttothe objecttype(identiedbythecolumn).IntheDCS-ACmodel,w eareconcerned withtwoadditionalaspects,decisiontemplateandtarget. Thedecisiontemplateisapointertosomevotingtemplate(s eeSection6.2.2) whichshouldbeinvokedinordertomakeadecisionontheacce ssrequest.We expectmostentriesinthematrixtopointtothe Always-yes templatewhichsimply returnsa yes withoutcallingforavote.Typically,requeststhatresult ingranting arighttosomerolemightrequireavotebutoncegranted,exe rcisingthatright maynotrequireone.Itisuptotheuserstodecidewhichreque stsrequireavote andwhichdonotrequireone.Needlesstosay,anyrequesttha trequiresavote willtakesometimetobeprocessedandso,thegrouppolicies shouldbedesigned carefully. 33

PAGE 44

34 Thetargeteldisaverypowerfulideawhichhelpsusachieve ne-grained accesscontrol(seeSection4.6.5).Insteadofsaying\role President canallow subjectstobindtotherole ExecutiveMember ",byusingatargeteld,wecan specifytherightinnerdetailbysaying\role President canallowsubjectsof role TrustedMember tobindtotherole ExecutiveMember ".Here,thetargetisthe role TrustedMember sincewearenarrowingdownthescopeofthisrighttojust thisrole.Dependingonthetypeofcommandbeingexecuted,t hetargetcanbea role,objecttypeoraright.Inthecaseofrightsforwhichth etargeteldisnot applicable,itis null andthekeyword any speciesthattherightcanbeexercised onanytarget. Thedistributionofrightsinthesystemarecanbeviewedasa naccessmatrix (implementedasave-eldRDBMStable), A .Thecell A [ X;Y ]containsaset of( ;Z;dp )tupleswhere isarightwhichrole X hasforobjectsoftype Y with respecttoatarget, Z and dp isapointertoadecisiontemplatethatmustbe activatedeachtime X makesarequesttoperform on( Y;Z ). Weachieveagreatdealofrexibilitybyallowingthegroupto dynamically changeamajorpartofthesystemcomponents.UnliketheTAMm odel,weallow types(i.e.,rolesandobjecttypes)andtypebindings(subj ect-roleandobject-type bindings)tobeaddedanddeleteddynamicallybythegroupac cordingtothegroup policyasrepresentedbythematrix.Similarly,thesetofri ghtsandtheavailable decisiontemplatescanalsobechangedwhilethesystemisin operation.Theonly staticcomponentofthemodelisthesetofcommandswhichare thesameforall instancesofthemodel. Eachsubjectcanbindtooneormore roles butatanypointoftime,the subjectcanbeactiveinonlyonerole.Theusercantemporari lychangehis/her activeroletoanotherroletomakearequestthatisnotallow edforhis/hercurrent role.Oneofthemainreasonsforthisrestrictionisthatthe userhastobeaware

PAGE 45

35 oftheincreasedresponsibilitywhilerequestingaccessth atrequiresmembershipto aprivilegedrole.Eachobjectisboundtoone objecttype .Thesebindingscanbe changedbyanyonewhohastherighttodoso.Thisisamajordi erencefromthe TAMmodelinwhichthebindingsareapartofthesystemdenit ionandcanonly bealteredbyanexternaladministrator.IntheDCS-ACmodel ,theadministrator isconsideredtobeapartofthesystemandissubjecttotheac cessrestrictions imposedbythematrix.An instance ofDCS-AChasthefollowingnitedynamic sets: asetofaccessrightsdenotedby R asetofdecisiontemplatesdenotedby D asetofobjecttypesdenotedby T asetofrolesdenotedby T R ( T ), asetofobjectsdenotedby OBJ ,and asetofsubjectsdenotedby SUB Theaccesscontrolmatrixisdenotedby A .Wehavethreemappingfunctions, f r whichmapseachsubjecttoasubsetof T R (correspondingtotherolestowhich thesubjectcanbind), f o whichmapseachobjecttoanelementof T (itsobject type) 1 ,and f a whichmapseach active subjecttohis/her active role. f r : SUB 2 T R f o : OBJ T 1 Ifanobjectisallowedtobeofmorethanonetype,accesscont roldecisionsare dicult.Shouldauserhaverightstoaccessallobjecttypes ofanobjectinorder toaccesstheobject?Analternativeistodeneanobjecttyp ehierarchy,which increasesthecomplexityofthemodel.

PAGE 46

36 Table4{1:ExampleofDCS-ACMatrixFragment Role ObjectType Target Right Template 1 Programmer Code null Read d yes 2 Programmer Code null Write d yes 3 Programmer Code Read GrantRight d 1 f a : SUB T R ThestateofaDCSsystemisthetuple( A;R;D;T;T R ;OBJ;SUB;f r ;f o )andas notedearlier,thesetofcommands C (denedinsection4.4)istheonlystatic componentofthemodel.Afewsimpleexamplesofthematrixen triesaregivenin table4.2.Here,ProgrammerisaroleandCodeisanobjecttyp e.Read,andWrite areaccesstypesand d yes isapointertothe Always-yes template.Therstthree entriesallowsubjectwhoareactivelyintheroleProgramme rtoreadandwrite objectsoftypeCode.ThethirdentryallowsProgrammerstog rantReadaccess toanyoneifthedecisiontemplate d 1 returnsyes.Thedecisiontemplate d 1 might requiretheapprovaloftheProjectLeaderandDevTeamManag er. GrantRight is aspecialaccessrightthatcorrespondstoaprimitiveopera tionthataddsanentry tothematrix. 4.3 Operations Letsusnowlookattheprimitiveoperationsthatcanbeexecu tedonaDCSACsystem.Theseareoperationsthatmodifyoneormorecompo nentsofthe systemandareguaranteedtobeatomic.Wewillformallyden etheoperations byspecifyingtheireectonthesystem.Let( A;R;D;T;T R ;OBJ;SUB;f r f o )denotethesystembeforetheoperationand( A 0 ;R 0 ;D 0 ;T 0 ;T 0 R ;OBJ 0 ;SUB 0 ; f 0 r f 0 o )denotethesystemaftertheoperation.Table4.3denesthe primitive operationsinDCS-AC.Notethatsetsnotmentionedinthede nitionofan operationareunchangedbythatoperation.Thereisonecomm andforevery operationbutwemightwanttohavecommandswithtwoorthree operations especiallyifwewantrolesandobjecttypestohavepedigree (seesection7.1).

PAGE 47

37Table4{2:SpecicationofDCS-ACOperations Operation Precondition Postcondition grantright( r;ot;;t;dp ) r 2 T R ;t 2 T [ R; 8 ( r 1 ;ot 1 ) 2 T R T t 2 T; 2 R;dp 2 DT; (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 dp 1 2 DT; A 0 [ r;ot ]= A [ r;ot ] [f ( ;t;dp ) g ( ;t;dp 1 ) = 2 A [ r;ot ] revokeright( r;ot;;t ) r 2 T R ;t 2 T [ R 8 ( r 1 ;ot 1 ) 2 T R T ot 2 T (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 2 R A 0 [ r;ot ]= f ( 1 ;t 1 ;dp 1 ): ( 1 ;t 1 ;dp 1 ) 2 A [ r;ot ] ^ ( 1 6 = ) ^ ( t 1 6 = t ) g createrole( r ) r= 2 T R T 0 R = T R [f r g 8 ( r 1 ;ot 1 ) 2 T R T;A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 ot 1 2 T;A 0 [ r;ot 1 ]= ; deleterole( r ) :9 s;f r ( s )= f r g T 0 R = T R f r g 8 ( r 1 ;ot 1 ) 2 T 0 R T A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 s 1 2 SUB;f 0 r ( s )= f r ( s ) f r g createot( ot ) ot= 2 T T 0 = T [f ot g 8 ( r 1 ;ot 1 ) 2 T R T 0 ;A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 r 1 2 T R ;A 0 [ r 1 ;ot ]= ; deleteot( ot ) :9 o;f o ( o )= ot T 0 = T 0 f ot g 8 ( r;ot ) 2 T R T 0 ;A 0 [ r;ot ]= A [ r;ot ] addobject( o;ot ) o= 2 OBJ OBJ 0 = OBJ [f o g ot 2 T 8 o 1 2 OBJ;f 0 o ( o 1 )= f o ( o 1 ) f 0 o ( o )= ot delobject( o ) OBJ 0 = OBJ f o g 8 o 1 2 OBJ 0 ;f 0 o ( o 1 )= f o ( o 1 ) addsubject( s;r ) r 2 T R SUB 0 = SUB [f s g 8 s 1 2 SUB;f 0 r ( s 1 )= f r ( s 1 ) f 0 r ( s )= f r g

PAGE 48

38Table4.2:Continued Operation Precondition Postcondition delsubject( s ) SUB 0 = SUB f s g 8 s 1 2 SUB 0 ;f 0 r ( s 1 )= f r ( s 1 ) addaccess( ) R 0 = R [f g delaccess( ) R 0 = R f g 8 ( r;ot ) 2 T R T A 0 [ r;ot ]= f ( 1 ;t;dp ):( 1 ;t;dp ) 2 A [ r;ot ] ^ ( 1 6 = ) g addrolebinding( s;r ) s 2 SUB 8 s 1 2 SUB f s g ;f 0 r ( s 1 )= f r ( s 1 ) r 2 T R f 0 r ( s )= f r ( s ) [f r g delrolebinding( s;r ) s 2 SUB 8 s 1 2 SUB f s g ;f 0 r ( s 1 )= f r ( s 1 ) r 2 T R f 0 r ( s )= f r ( s ) f r g f r ( s ) 6 = f r g changedp( r;t;ot;;dp ) r 2 T R ;t 2 T [ R 8 ( r 1 ;ot 1 ) 2 T R T ot 2 T (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 2 R A 0 [ r;ot ]= f ( 1 ;t 1 ;dp 1 ):( 1 ;t 1 ;dp 1 ) 2 A [ r;ot ] ^ 1 6 = ^ t 1 6 = t g dp 2 DT [f ;t;dp g changeot( o;ot ) o 2 OBJ 8 o 1 2 OBJ;o 1 6 = o f 0 o ( o 1 )= f o ( o 1 ) ot 2 T f 0 o ( o )= ot

PAGE 49

39 4.4 CommandsinDCS-ACModel Theaccesscontrolmatrixcanonlybemodiedthroughtheset ofcommands whichistheonlystaticcomponentintheDCS-ACmodel.Unlik etheHRUand othermodels,thesetofcommandsdoesnotvaryfromsystemto system.There isonecommandforeachprimitiveoperation;itchecksifthe subject'srolehas therighttoperformtheoperationandifso,thenitperforms theoperation.A command consistsoftwoparts:aconditionalpartthatchecksifther oleisallowed tomaketherequestandanexecutionpartthatexecutesoneop eration.Allobjects belongingtotheaccesscontrolmodel(like A;f o ;DT;T;T R etc.)areoftheobject type.GivenbelowisthelistofcommandsinDCS-AC.Inallth esecommands, r istheroleofthesubjectexecutingthecommand. commandCreateRole( r 2 T R ;r new = 2 T R ) if(( CREATEROLE,null,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then createrole ( r new ) commandDeleteRole( r 2 T R ;r 1 2 T R ) if :9 s;f r ( s )= f r 1 g and(( DELETEROLE, null ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and dp returns true then deleterole ( r 1 ) commandGrantRight( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R;dp 1 2 DT ) if :9 dp 2 ; ( ;t;dp 2 ) 2 A [ r 1 ;ot ] and(( GRANTRIGHT, ,dp ) 2 A [ r;ot ] )for some dp 2 DT and dp returns true then grantright ( r 1 ;ot;;t;dp 1 ) commandRevokeRight( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R ) if(( REVOKERIGHT, ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then revokeright ( r 1 ;t;ot; ) commandCreateOT( r 2 T R ;ot= 2 T ) if(( CREATEOT, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then createot ( ot )

PAGE 50

40 commandDeleteOT( r 2 T R ;ot 2 T ) if :9 o;f o ( o )= ot and(( DELETEOT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then deleteot ( ot ) commandAddSubject( r 2 T R ;s new = 2 SUB;r initial 2 T R ) if(( ADDSUBJECT, r initial ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then addsubject ( s;r initial ) commandDelSubject( r 2 T R ;s 2 SUB ) if(( DELSUBJECT, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then delsubject ( s 1 ) commandAddObject( r 2 T R ;o= 2 OBJ;ot 2 T ) if(( ADDOBJECT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then addobject ( o;ot ) commandDelObject( r 2 T R ;o 2 OBJ ) if(( DELOBJECT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then delobject ( o ) commandAddRoleBinding( r 2 T R ;s 2 S;r 1 2 T R ) if(( ADDROLEBINDING, r s ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and r s 2 f r ( s ) and dp returns true then addrolebinding ( s;r 1 ) commandDelRoleBinding( r 2 T R ;s 2 S;r 1 2 T R ) if f r ( s ) 6 = f r 1 g and(( DELROLEBINDING, null ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and dp returns true then delrolebinding ( s;r 1 ) commandChangeOT( r 2 T R ;o 2 OBJ;ot new 2 T ) if(( CHANGEOT, f o ( o ) ,dp ) 2 A [ r;ot new ] )forsome dp 2 DT and dp returns true then changeot ( o;ot new ) commandAddAccess( r 2 T R ;= 2 R ) if(( ADDACCESS, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then addaccess ( )

PAGE 51

41 commandDelACCESS( r 2 T R ; 2 R ) if(( DELACCESS, ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then delaccess ( ) commandChangeDP( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R;dp new 2 DT ) if 9 dp 1 ; ( ;t;dp 1 ) 2 A [ r 1 ;ot ] and(( CHANGEDP, ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then changedp ( r 1 ;t;ot;;dp new ) Itisobviousthatallthecommandscanbeexecutedinconstan ttime(assuminganthatlookinguptheaccessmatrixandotherDCS-ACc omponentscan bedoneinconstanttime).Moreover,therolesandobjecttyp escreatedbythe CreateRole and CreateOT commandshavenopedigree,i.e.,thecreatoroftherole orobjecttypehasnospecialrightsoverthatroleorobjectt ype.Wealsoallowthe objecttype,accessrightandthetargettobereplacedbythe keyword ANY .For example,if( ANY;ANY;dp ) 2 A [ Secretary;ANY ]where dp isadecisiontemplate thatcallsforasimplemajorityofallsubjectswhocanbindt otherole Senator thenaSecretarycanmakeanychangetothesystemifapproved byamajority ofthesenators.Sincetherolesandobjecttypeshavenopedi gree,therehasto beagrouppolicyforgrantingrightstotheserolesandobjec ttypes(typically, ( GRANTRIGHT;ANY;someDP ) 2 A [ SomeRole;Any ]). 4.4.1 Constraints Thereareafewconstraintsthathavetobeenforcedonthesys tem,someof whichhavebeenmentionedearlier. ActiveRole Atnopointoftimecanasubjectbeactiveinmorethanone role. RoleAuthorization Asubjectcanonlybeactiveinroleshe/sheisauthorized tobein. OperationAuthorization Asubjectcanperformonlythoseoperationsthat his/heractiveroleisauthorizedtodo.

PAGE 52

42 ObjectAccessAuthorization Asubjectcanonlyaccessthoseobjectshis/her activeroleisauthorizedtodo. AmendmentRule Thereshouldalwaysbearulethatallowsthegroupto modifyanycomponentofthesystem. DeleteRestriction Aroleorobjecttypecannotbedeletedifitresultsina violationoftherulesandconstraints. GracefulDeletion Ifanactivesubjectisdeletedfromthesystem,thedeleted subjectshouldloseallrightimmediately. DecisionTemplateOverwriteRule A GrantRight commandshouldnotbe allowedtochangethedecisiontemplateofanalreadygrante dright. The ActiveRole constraintisenforcedtosimplifytheaccesscheckingproc ess.The RoleAuthorization OperationAuthorization ,and ObjectAccessAuthorization areRBACenforcedconstraints. AmendmentRule islikeanemergencyoverride toallowthegrouptorecoverfromunusablestates.Typicall y,thisisenforcedby amatrixentrythatallowsaparticularroletochangeanythi ngifsometemplate returnsayes.Forexample,the Chairman canchangeanyruleifallthe Faculty andthe CollegeDean agree. The DeleteRestriction isimposedondeletionofrolesandobjecttypes.If thereisasubjectthatcanbindtoonlyonerole,thendeletin gthatrolemeansthat thesubjectcannotbindtoanyrole.Thisisaninconsistents tateandshouldbe avoided.Thissubjectshouldbedeletedorallowedtobindto anotherrolebefore deletingthisrole.Furthermore,ifthereisasubjectcurre ntlyactiveinaparticular role,thenthatrolecannotbedeleted.Similarly,iftherei satleastoneobjectthat belongtoaparticulartype,thattypecannotbedeleted. The GracefulDeletion ruleisfordeletingsubjectswhoarecurrentlyactive. Theyshouldbeimmediatelyloggedoutofthesystemwithsuit ablenotication messages.The DecisionTemplateOverwriteRule preventssomesubjectfrom changingthedecisiontemplateforanentryinthematrixbyu singthe GrantRight

PAGE 53

43 command.Thisisenforcedbyensuringthatno GrantRight commandgrantsan alreadyexistingcommand.Thedecisiontemplatepointersf oranentrycanonlybe changedbythe ChangeDP command. 4.4.2 ExpressivePower ItiswellknownthattheHRUmodelhasverygoodexpressivepo werbutis veryweakintermsofprovablesafety.ItcanbeseenthattheD CS-ACmodelalso hasverygoodexpressivepower.AnyHRUprotectionstatecan beconvertedtothe DCS-ACmodel. MappingfromHRUtoDCS-ACConsideraprotectionsystem( R;C )andastate( S;O;P ).Letusdeneanew roleforeachuserandallowonlythatusertobindtothatrole andcallthesetof theseroles T R .Similarly,deneanewobjecttypeforeachobjectandcallt hisset T .Wedene DT = f dp g where dp isapointertoadecisiontemplatethatalways return yes .LetthenewDCS-ACinstancebe( R DT T T R O S f o f r A ). 8 o i 2 O addanewobjecttype ot i to T andlet f o ( o i )= ot i 8 s i 2 S addanewrole r i to T R andlet f r ( s i )= f r i g A [ r i ;ot i ]= f ( ;null;dp ): 2 P [ s i ;o i ] g NowwehaveaninstanceofDCS-ACmodeldenedby( R DT T T R O S f o f r A ).Althoughthesystemstateinthetwomodelsareequivalent ,thesystems themselvesarenotequivalentbecausewehavenotmappedthe commandsofthe HRUmodeltosomethingequivalentintheDCS-ACmodel. MappingfromDCS-ACtoHRUSimilarly,wecandoamappingfromDCS-ACtoHRU.Hereagain, thetwo systemswillnotbeequivalentbecauseofdynamictypingand decisionpointers. ConsideraninstanceoftheDCS-ACmodel( R;DT;T;T R ;OBJ;SUB;f r ;f o ;A ).

PAGE 54

44 WecanconvertthisintoaHRUsystem( R 0 ;C )withtheconguration( S;O;P )as follows: 1. R 0 = R R m where R m isthesetofallmatrixmanipulationoperations notsupportedbyHRU. 2. S = SUB and O = OBJ 3. 8 ( s;o ) 2 SUB OBJ (a) 8 r 2 f r ( s ) ;P [ s;o ]= f :( ;null;dp ) 2 A [ r;f o ( o )] ^ = 2 R m g 4.Addcommandstoperformeachofthesixoperationsifthesu bjecthasthe rightsimilartotheonespeciedinsection4.4. NotethattheresultingHRUinstanceisamono-operationalo neandhencethe safetyofthisisdecidableinNPtime.Here,wedropalltypin ginformation, decisionpointersandoperationsnotallowedbyHRU. 4.5 Comparisonwithexistingmodels OnemajordierencebetweentheDCS-ACmodelandtheothermo delsisthe factthattheACMitselfisanobjectandthereisarightcorre spondingtoeachof theabovementionedoperations.Ifauserwantstoperformam atrixmodifying operation,thenhis/herroleshouldhavetherighttodoso.I tmustbenotedthat inTAM, R;T;T R and t areallpartofthesystemdenitionandcannotbealtered byanyonewithinthesystem,whereastheseareapartoftheDC S-ACmodel instanceandcanbemodiedbyanyonewhohastherighttodoso .TAMdoesnot havethenotionofdecisionpointerseither.TAMallowsanyn umberofparameters initscommandsbuttheDCS-ACallowsatmostve. HRUTAM +Strong Typing + Dynamic Typing+ Decision Pointers DCS Arbitrary Commands Figure4{1:ComparisonofHRU,TAMandDCS-ACmodels TheTAMmodeladdedthenotionofstrongtypingtotheHRUmode l. TheDCS-ACmodelhasdynamictyping,staticsetofcommands( asopposedto

PAGE 55

45 arbitrarycommands)andmostimportantofall,decisiontem platepointersthat allowsthemembersofthegrouptodecideonaccessrightissu es.Anothermajor dierenceisthedynamicsetofaccessrights.Asmentionede arlier,theterm role asusedintheDCS-ACmodelisdierentfromwhatitmeansinRB AC.Hereare somedierencesbetweenthetwo: RoleHierarchy Thereisnorolehierarchyinthecurrentimplementationof theDCS-ACmodel.Subsection7.3talksabouthowtheDCS-ACm odelcan beextendedtoimplementrolehierarchy. StaticSeparationofDuty TheDCS-ACmodeldoesnotsupportstaticseparationofduty.However,itispossibletoimplementdynami cseparationof dutyusingfunctioncalls.Allseparationofdutypoliciesc anbeimplemented asdynamicwhichprovidesgreaterrexibilitytotheusers. DecisionPointers Theuseofdecisionpointersisthenewparadigmintroduced inthismodel.Asmentionedearlier,thisadditionisveryus efulinspecifying varioussystempolicies. 4.6 FeaturesofDCS-ACModel Theaccesscontrolmatrixandthefunctionsmappingvarious setsarestored astablesinabackenddatabasewhichisreplicatedacrossal lsites.Allupdates anddeletionsarepropagatedtoothersitesbyaseparateDat abaseServicesmodule (DBS)whichguaranteesprocessorconsistencyforupdates, i.e.,updatesoriginating fromthesameprocessorwillbecommittedatallsitesinthes ameorder.This isachievedbyassigninganownersiteforeachtupleintheta ble.Whenanew tupleistobeadded,thesitetherequestoriginatedistheow ner.Modications toaparticulartupleareforwardedtoitsownerwhichthenmu lticaststoother sites.ThedecisiontemplatesaremaintainedbytheDecisio nSupportServices module(DSS)whichstoresthevoteparticipants,percentag eofvotesrequiredfor successandotherinformationaboutthetemplate.Whenthea ccesscontrolmodule initiatesadecision,theparticipantsarenotiedandthev otesarecollected.Once adecisionisreached,theDSSpassesittotheaccesscontrol modulewhichtakes

PAGE 56

46 furtheractionasrequired.Notethatinmanycases,thedeci sionpointermaypoint toatemplatethatalwaysreturnsa yes 4.6.1 DecisionTemplates Decisiontemplatesareoneofthemostinterestingfeatures oftheDCS-AC model.Theuseofgroupvotingmechanismsallowtheuserstos elf-administertheir groups.Itisquiteclearthatthesafetyofthesystemwillde pendveryheavily onthedecisionpointer.Itwillbeveryinterestingtostudy thevarioustypesof collusionattackspossiblebasedonagivensetofdecisionp ointers.Adecision templatecontainsthefollowinginformation:(i)Alistofv otersalongwiththe weightofeachentity's(role/subject)vote,(ii)numberof votersforquorum,(iii) startandendtimes,(iv)percentageofvoterwhohavetoagre eforthevotetopass, (v)defaultpoliciesifquorumisnotreached,and(iv)other bookkeepingdetailslike whoshouldbenotiedoftheresultetc.Thetemplatealsospe cieswhatkindof votetostart(ranking,simplemajority,multiplerounds,e tc.).Itisexpectedthat mostaccessrequestswillinvokeasimpledecisiontemplate thatalwaysreturns yes andonlyafewaccessrequests(likegrantingarighttoarole oranythingdeemed importantbythegroup)willrequireavote. Ifweallowthedecisionpointerstobepointerstoavotingpr ocessora functioncallthatreturnsadecisionbasedonthestateofth esystem,wecan implementinterestingpoliciesliketheseparationofduty .Iftheglobalpolicy statesthatanyuserwhohasaccesstoobjectsoftype O 1 shouldnothaveaccess toobjectsoftype O 2 ,thenthedecisionpointerwillexecuteafunctionthatallo ws theaccessonlyifthecellcorrespondingto[ R;O 1 ]isnullforevery R inthesetof allrolesthesubjectcanbindto.However,theuseoffunctio npointersmightmake theaccessrightleakageproblemundecidableandiscurrent lynotapartofthe DCS-ACmodel.

PAGE 57

47 4.6.2 DynamicTypeBinding Thebindingbetweenobjects/subjectsandtheirtypesissta ticinTAM(HRU doesnothavetypes).Therearemanyscenariosinwhichthisb indinghastobe changed.Byallowingthebindingstochange,wecanalsomode lprocesswork rows.Forexample,ifthegrouppolicystatesthatthereview teamshouldnot beabletoaccessthecodeuntilitpassesthetestingphase.W ecandenethree dierentobjecttypes, workingcode,ready-for-test and ready-for-review .Whenthe codeisreadyfortesting,theprojectleaderorthedevelope rcanchangetheobject typeofthelesto ready-for-test .Nowthetesterscandotheirjob.Anadditional advantageindoingthingsthiswayisthattheprogrammersca nnotmodifytheles thatarebeingtested(iftheydonothavethataccessforobje ctsoftype ready-fortest .Ifthecodefailstesting,thePLcanchangeitstypebackto workingcode else, he/shecanchangeitto ready-for-review 4.6.3 DynamicsetofAccessRights Asmentionedearlier,oneofthedierencesbetweentheDCSACmodeland theothermodelsisthefactthattheaccessrightsarenotapa rtofthesystem denition.Whenanewapplicationisaddedtoasystemwithas taticsetofaccess rights,ne-grainedaccesscontrolhastobemanagedbythea pplicationitself.In theDCS-ACmodel,whenanewapplicationisadded,wecanden enewaccess typestothesystemandmakeaccesscontroldecisionsatthes ystemlevel.For example,ifanewaudio-videoapplicationisadded,wecande nenewaccesstypes like playaudiole recompressthele cutandcroples ,etc.Now,basedonthe roles(likeproducer,soundengineer,etc.)itisstraightf orwardtodeneaccess controlpolicieslikeaproducercanplayanaudiolebutcan notmodifyit,a soundengineercanplay,recompress,cutandcropanaudiol e.Wecanalsodene specialrelationssothatonlytheproducersandsoundengin eersworkingwitha

PAGE 58

48 particularartistcanaccesstheaudiolesrecordedbythat artist.Aswecansee, therealmofpossibilitiesisverylarge. 4.6.4 DynamicsetofObjectTypes Inmostrealworldscenarios,itisimpossibletokeeptheset ofobjecttypesa constant.Wecannotforeseeallpossibleobjecttypesdurin gsysteminitiationand althoughtheneedmaynotbeveryfrequent,itisverylikelyt hatanysystemwill neednewobjecttypesatsomepointoftime.Whenatheaudio-v ideoapplication mentionedintheprevioussectionisinstalled,wehavetocr eateanewobject type(called audiole ).Itisquitepossibletojustusethetype genericle and individuallyspecifytheaccessrightsforeachaudiole.T hisishowitwillhaveto bedoneinTAM.However,themainadvantageofusingtypesist hereductionin thesizeoftheACMandhence,specifyingtherightsforeacha ndeveryaudioleis counter-productiveintermsofACMsize.Thusitismorelogi caltoallowthesetof objecttypestochangewiththeneedsoftheusers. 4.6.5 FineGrainAccessControl AscanbeseenfromthecommandsinDCS-AC(Section4.4),theu seof the target eldallowsustodeneverynegrainedaccesscontrolpolic ies.For example,wecanspecifythatrole r hastherighttogrant read accesstoobjectsof type ot (( GRANTRIGHT;read;dp ) 2 A [ r;ot ])andwecansimilarlyspecifyrevoke rightsforspecicaccesses.Anotherinstanceofnegraine daccesscontrolisthe ChangeOT command.Ifamanagercandeclassifya TopSecret documentto Secret buttooonlywiththeapprovaloftheCEO,then( CHANGEOT;Secret;dp 1 ) 2 A [ Manager;TopSecret ]where dp 1 isadecisiontemplatethathasonlyonevoter, theCEO.Thislevelofgranularityisnotavailableinmostac cesscontrolmodelsin usetoday.

PAGE 59

49 4.7 DCS-ACModelSolutionforSoftwareProjectExample Hereisasolutiontothesoftwareprojectexamplementioned insectionrefmotivationusingtheDCS-ACmodel.Letthesetofrolesbe T R = f PL,Architect, Prog,Tester g .Whentheproject(letscallitX)isstartedthefollowingob ject typesarecreated: XDesignDoc,XCode,XWorkingCode,XTestedCode and XShipCode .Thefollowingrolesarealsocreated: XPL,XArchitect,XProg and XTester Wenowaddtheentriesspeciedintable4{3totheaccesscont rolmatrix, A Here, dp 1 isadecisionpointerthatalwaysreturns yes dp 2 requiresavoteof allsubjectswhocanbindto XProg and dp 3 requiresavoteofallsubjectswhocan bindto PL .Entries1,2and3allowtheXPLtodecidewhoworksonaprojec t butensuresthatpolicy6(PLcannotchangetheroleofanempl oyee)isenforced. Thisisasimplisticviewofthingsanditisveryeasytoenvis ionasystemwhere compile and execute arevalidaccesseswhichareusedbyaDCS-awaredevelopment environment. ThusclasslibrariesexampleissolvedbyusingtheDCS-ACmo del.Similar solutionsaresuitableforcollaborativecontractediting andmanyotherdistributed collaborativeapplications.Thisexamplealsoillustrate showtheDCS-ACmodel canbeusedtomodelprocessworkrow.

PAGE 60

50Table4{3:DCS-ACSolutionforSoftwareProjectExample No. Entry Explanation 1 ( ADDROLEBINDING;Architect;dp 1 ) 2 A [ XPL;XArchitect ] ThePLcanassignarchitects totheproject 2 ( ADDROLEBINDING;Prog;dp 1 ) 2 A [ XPL;XProg ] PLcanaddprogrammersto theproject 3 ( ADDROLEBINDING;Tester;dp 1 ) 2 A [ XPL;XTester ] PLcanaddtestersto theproject 4 ( ADDOBJECT;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscancreatedesign documentation 5 ( read;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscanreadthedocs 6 ( read;null;dp 1 ) 2 A [ XPL;XDesignDoc ] ThePLcanreadthedocs 7 ( write;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscanwritetodocs 8 ( read;null;dp 1 ) 2 A [ XProg;XDesignDoc ] Programmerscanreadthedocs 9 ( ADDOBJECT;null;dp 1 ) 2 A [ XProg;XCode ] Progscancreatecodeles 10 ( read;null;dp 1 ) 2 A [ XProg;XCode ] Progscanreadthecodeles 11 ( read;null;dp 1 ) 2 A [ XPL;XCode ] PLcanreadthecodeles 12 ( write;null;dp 1 ) 2 A [ XProg;XCode ] Progscanwritetothecodeles 13 ( CHANGEOT;XCode;dp 2 ) 2 A [ XProg;XWorkingCode ] Progstakeavotetosubmit codefortesting 14 ( read;null;dp 1 ) 2 A [ XTester;XWorkingCode ] Testerscanreadworkingcode 15 ( CHANGEOT;XWorkingCode;dp 1 ) 2 A [ XTester;XCode ] Testerscanreturncode toprogrammers 16 ( CHANGEOT;XWorkingCode;dp 1 ) 2 A [ XTester;XTestedCode ] Testerscanmarkcodeready forreview 17 ( read;null;dp 1 ) 2 A [ PL;XTestedCode ] AllPLsinthecompanycan lookattestedcode. 18 ( CHANGEOT;XTestedCode;dp 3 ) 2 A [ XPL;XShipCode ] PLcanshipcodeif reviewteamagrees

PAGE 61

51 4.8 Summary Inthischapter,wedenedanddiscussedtheDCS-ACmodel.On eofthemain featuresofthismodelistheabilityofthesubjectstovoteo nimportant(asdened bythegroup)decisions.Allsubjectsbelongtooneormorero lesandallobjects belongtoanobject-type.Theaccessmatrixentryforaparti cularroleandobject typecontainsasetoforderedpairscorrespondingtotherig htstherolehasover theobjecttypeandthedecisiontemplatethatisexecutedwh enasubjectofthat roletriestousethatparticularrightovertheobjecttype. Thedecisiontemplate mightpointtothe Always-yes template(whichalwaysreturns yes )oranyother templatedenedbythegroup.Therearesixteenprimitiveop erationsandsixteen commands(eachofwhichcorrespondtooneoftheoperations) .Thesearethe onlystaticcomponentsofthemodel.Thegroupcandeneandm odifyallother componentslikeroles,objecttypes,etc.dynamically.The reareafewconstraints thathavetobeenforcedwhenimplementingthismodel.Theco mmandsinDCSACaredesignedinsuchawaysoastoallowne-grainedaccess control,i.e.,we canspecifyruleslike RoleXcanallowasubjectofroleYtobindtotheroleZ insteadofjustamoregeneralrulelike RoleXcanallowasubjecttobindtoroleZ Itshouldberememberedthatwhileallthesefeaturesarerea llypowerful,care mustbetakentoavoidgettingintoastatethatmakesthesyst emdiculttouse. The AmendmentRule constraintenablesthegrouptorecoverfromanysuchbad states.Inthenextchapter,wewillprovethatthemodelispr ovablysafe.

PAGE 62

CHAPTER5 SAFETYANALYSIS 5.1 Introduction Thepresenceofdecisionpointersmakesthesafetyanalysis oftheDCS-AC modelverytricky.ConsiderarestrictedversionofDCS-ACw herethereisonly onedecisionpointerinthesystem, dp ,andthatpointeralwaysreturns true .This isavalidrestrictionbecause,iftrusteddeciderscontrol adecision,theywillvote no ,sowecanremovetheseentriesfromthematrixandanydecisi oncontrolledby untrusteddeciderswill,intheworstcase,alwaysresultin yes .Wewillrstanalyze thesafetyofsucharestrictedmodelandinthenextchapter, wewilldiscussthe safetyofthefullmodel. 5.2 Denitions Letusnowlookatsomedenitionsthatwillhelpusunderstan dthesafety propertiesoftheDCS-ACmodel.Denition Thestate, S ,ofaDCS-ACsystemisasnapshotofthesystemata giventime.Itconsistsoftheaccesscontrolmatrix A ,therolebindingfunction f r theobjecttypebindingfunction f o ,andthefollowingsets: setofrights R setofsubjects SUB setofobjects OBJ setofobjecttypes T setofroles T R ( T R T ),and setofdecisiontemplates DT 52

PAGE 63

53 Denition Foragivenstate S ,objecttype ot ,andright S;;ot = f s : s 2 SUB ^9 r 2 f r ( s ) ;t 2 ( T [ R [; )suchthat( ;t;dp ) 2 A [ r;ot ] g Inotherwords, S;;ot isthesetofallsubjectswhohavetheright forobjectsof type ot in S .Wecangettheset S;;ot in O ( j SUB jj T R jj R j )timeasfollows: functiongetPhi( S;;ot ) 1. result = ; 2.forall s 2 SUB (a)forall r 2 f r ( s ) i.forall ( 0 ;t 0 ;dp ) 2 A [ r;ot ] A.if 0 = then result = result [f s g Processnext s 3.return result Denition Giventwostates, S and S 0 ,andacommand, ,wesay S* S 0 ifthe command canbeexecutedon S and S 0 istheresultofperformingtheoperation in on S (i.e.,applying on S resultsin S 0 ). Denition Giventwostates S and S 0 ,andasequenceofcommands (containing k commands, 1 ; 2 ;:::; k ),wesay S S 0 if 8><>: k =0 ) S = S 0 k =1 ) S* 1 S 0 k> 1 ) S* 1 S 1 ^ S 1 0 S 0 ; where 0 = 2 ; 3 ;:::; k Denition ForagivenDCS-ACstate S ,object o ,andright ,wesaythata sequenceofcommands resultsinaleakingstateifandonlyif S S 0 ) S 0 ;;f 0 o ( o ) S;;f o ( o ) 6 = ; Letusnowdenetheaccessrightleakprobleminthecontexto ftheDCS-AC model.

PAGE 64

54 Denition ForagivenDCS-ACstate S ,object o ,andright ,theaccessright leakproblemisadecisionproblemisthequestion,doesther eexistasequenceof commandson S thatresultsinaleakingstate. 5.3 AttributesofaState Inordertohelpuskeeptrackofthecommandsthathavebeenex ectutedand thosethatcanbeexecuted,weidentifycertainattributesw hicharedependenton thecurrentstateofthesystem.Eachoftheseattributescan beactive(i.e.,the commandhasbeenexecuted),enabled(thecommandhasnotbee nexecutedbut thereissomeroleinthecurrentstatethatcanexecutetheco mmand),orinactive (thecommandhasnotbeenexecutednorcananyroleexecuteth ecommandinthe currentstate). Foranystate S t (reachedbyexecuting0ormorecommandsonthestarting state S 0 ),thefollowingattributesarevalid: 1. HasRight r 0 ;ot 0 ; 0 ;t Thisattributetracksthe GrantRight commandsand issaidtobeactivefor S t if( 0 ;t;dp ) 2 A ( r 0 ;ot 0 )forsome dp 2 DT Iftheattributeisnotactive,wesaythatthisattributeise nabledif 9 r;dp 0 suchthat( GRANTRIGHT;dp 0 ) 2 A ( r;ot 0 ) 2. CanBind s 0 ;r 0 Thisattributetrackssubject-rolebindingsandissaidtob e activefor S t if r 0 2 f r ( s 0 ).Iftheattributeisnotactive,wesaythatthis attributeisenabledif 9 r;dp 0 suchthat( ADDROLEBINDING;dp 0 ) 2 A ( r;r 0 ) Foragivenstartingstate S 0 andadescendantstate S t (reachedbyexecuting1or morecommandsonthestartingstate S 0 ,i.e., 9 suchthat j j 1 ^ S 0 S t ), weidentifythefollowingattributesthatarevalidfor S t andallstatesthatresultin executingasequenceofcommandson S t : 1. NewRole Thisattributeissaidtobeactivefor S t ifoneofthecommands wehaveexecutedon S 0 isa CreateRole command.Itcannotbeactivefor S 0 .Iftheattributeisnotactive,wesaythatthisattributeis enabledif 9 r;d 0 suchthat( CREATEROLE;d 0 ) 2 A ( r; )

PAGE 65

55 2. NewOT Thisattributeissaidtobeactivefor S t ifoneofthecommandswe haveexecutedon S 0 isa CreateOT command.Itcannotbeactiveforthe initialstate S 0 .Iftheattributeisnotactive,wesaythatthisattributeis enabledif 9 r;d 0 suchthat( CREATEOT;d 0 ) 2 A ( r; ) 3. NewSubject r 0 Thisattributeissaidtobeactiveforastate S t ifoneofthe commandsexecutedisa AddSubject commandwiththeinitialrole r 0 .These attributescannotbeactivefor S 0 .Iftheattributeisnotactive,wesaythat thisattributeisenabledif 9 r;dp 0 suchthat( ADDSUBJECT;dp 0 ) 2 A ( r;r 0 ) Theseattributesareactivatedbyexecutingthecorrespond ingcommands. Active ( S i )isthesetofattributesthatareactiveinastate S i and Enabled ( S i ) isthesetofattributesthatareenabledin S i 5.4 Proofs Letusnowlookatafewlemmasandtheoremsthatwillleadtoap olynomial timesolutiontotheARLproblemforatDCS-ACsystemwithout voting. Denition Wesaythattwostates S i and S j (withthesamestartingstate S 0 )are equivalent intermsofaccessrightleakageif: S i isaleakingstate S j isaleakingstate .Axiom1 InaDCS-ACsystemwithaninitialstate S ,twosequencesofcommands, 1 and 2 ,resultinequivalentstatesiftheactiveattributesofthe two resultingstatearethesame. ( S 1 S 1 ) ^ ( S 2 S 2 ) ^ ( Active ( S 1 )= Active ( S 2 )) ) S 1 S 2 Lemma2 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 resultsinaleakingstateand

PAGE 66

56 0 doesnotcontainanycommandthatrevokesarightordeletesa subject, object,role,objecttypeoraccess. Proof Let = 1 ; 2 ;:::; k andlet i betherstrevocationordeletioncommand. Let j (1 j k )bethesmallestnumbersuchthatthesequence 1 = 1 ;:::; j resultsinaleakingstate S 0 .Clearly, j 6 = i since i isarevocationor deletioncommand. Case1: ji Considerthesequence 2 = 1 ;:::; i 1 ; i +1 ;:::; j .Weknowthatthe commands i +1 ;:::; j canbeexecutedevenifwehadexecuted i (whichremoves somethingfrom S ).Moreover,allcommandscheckforthepresenceofsomerigh t andnotfortheabsence.Therefore,thecommandsin 2 canstillbeexecutedand hence,thissequencewillalsoresultinaleakingstate. Repeatingtheabovestepforallrevocationanddeletioncom mandsin ,we get 0 ,asequencewhichdoesnotcontainanyrevocationordeletio ncommandand resultsinaleakingstateif resultsinaleakingstate. Lemma3 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainany AddObject AddAccess ,or ChangeDP commands. Proof Let = 1 ; 2 ;:::; m andlet i bethecommandthataddsanewobject o 1 .Weconstruct 1 byremoving i andallothercommandsin thatchange

PAGE 67

57 theobjecttypeof o 1 .Since ChangeOT istheonlycommandthatdependsonthe existenceof o 1 ,alltheothercommandscanstillbeexecuted. Sincethepresenceorabsenceof o 1 doesnotaecttherightleakfor o (asper thedenitionofrightleakproblemabove),if resultsinaleakingstate,then 1 alsoresultsinaleakingstate. Repeatingtheabovestepsforall AddObject commands,wegetasequence 2 whichdoesnotcontainany AddObject commandsandresultsinaleakingstateif resultsinaleakingstate. Usingsimilararguments,wecanremoveall AddAccess commandsfrom 2 .Moreover,sincethereisonlyonedecisionpointerinthesy stem, ChangeDP commandscanignored. Sowenowhaveasequence 0 whichdoesnotcontainany AddObject,AddAccess or ChangeDP commandsandresultsinaleakingstateif resultsinaleaking state. Corollary4 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doescontainsonly CreateRole,CreateOT,AddSubject,GrantRight, AddRoleBinding, and ChangeOT commands. Lemma5 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethanone CreateRole andone CreateOT command.

PAGE 68

58 Proof Let = 1 ; 2 ;:::; m .Wewillconstructanewsequence, 1 ,asfollows: 1.Let create i newroles, r 1 ;r 2 ;:::;r i 2.Removeall CreateRole commandsin commandsexcepttherstone(only r 1 isadded). 3.Replacealloccurrencesof r j (1
PAGE 69

59 Let contain n commandsthataddanewsubjectwiththeinitialrole r 1 AddRoleBinding istheonlycommandotherthan AddSubject thatdirectly addressesasubject. Let } ( k;r 1 )bethestatementthatif adds k newsubjectswithinitialrole r 1 thenthereexistsasequenceofcommandsthatresultsinalea kingstateandadds onlyonenewsubjectwithinitialrole r 1 BaseCase: k =2 Whentherstsubject s 1 iscreated, f r ( s 1 )= f r 1 g .Whenthesecondsubject s 2 iscreated, f r ( s 2 ) f r ( s 1 ),therefore,anynewrolebindingaddedfor s 2 canalsobeaddedfor s 1 .Letusconstructanewsequence 1 byremovingthe AddSubject( r 0 ;r 1 ;s 2 ) command,replacingeveryoccurrenceof s 2 with s 1 inall AddRoleBinding commandsandretainingallothercommands. Let S S 0 and S 1 S 1 .Byconstruction, s 1 hasalltherightsin S 1 that s 2 hasin S 0 andneither s 1 nor s 2 wereapartof S .Wealsoknowthat S 0 isa leakingstate(since resultsinaleakingstate).Now,wewillprovethat S 1 isalso aleakingstate. Case1:Thenewlycreatedsubject s 2 causedtheleak. If s 2 getstheright over o in S 0 ,then s 1 gets over o in S 1 .Therefore,if s 2 wasthecauseoftheleakin S 0 ,then s 1 willcausealeakin S 1 Case2:Therightleakwasduetosomeothercommandin Sinceallthecommandsotherthanthosethathave s 2 asaparameterhave beenretainedin 1 ,ifcommandsotherthantheonesaecting s 2 causedtheleak in S 0 ,thenthosesamecommandswillcausealeakin S 1 .Therefore, S 1 alsoresults inaleakingstate. Hence,if addstwonewsubjectwithinitialrole r 1 ,thenwecangetanew sequencethatalsoresultsinaleakingstatebutcreatesonl yonesubjectwith initialrole r 1 .Therefore } (2 ;r 1 )istrue.

PAGE 70

60 InductionStep: Assume } ( k 1 ;r 1 )istrue( k> 2). Letthe k subjectsaddedby withinitialrolebe s 1 ;s 2 ;:::;s k .Wecanconstructasequenceofcommands, k whichdoesnotaddthesubject s 2 butstill resultsinaleakingstateusingtheconstructionmentioned above.Now,wehavea sequenceofcommandsthatadds k 1newsubjectswithinitialrole r 1 thatresults inaleakingstate. Since } ( k 1 ;r 1 )istrue,wecanreplace k withanewsequence 0 thatadds onlyonenewsubjectwithinitialrole r 1 andstillresultsinaleakingstate. } ( k 1 ;r 1 ) ) } ( k;r 1 ) Therefore,bytheprincipleofmathematicalinduction, } ( k;r 1 )istrueforall positiveintegervaluesof k .If k =0,thenwealreadyhaveasequenceofcommands thatresultinaleakingstateandaddsnomorethanonesubjec twithinitialrole r 1 Applyingtheaboveresultforeveryrole,wecanconstructas equenceof commandsthataddonlyonesubjectforeveryroleinthestate .Bylemma5,we canretainjustone CreateRole commandin ,thereforethenumberofrolesafter theexecutionofallcommandsisatmostonemorethanthenumb erofrolesin S .Thereforethenewsequencewillhaveatmost j T R j +1numberof AddSubject commands.Eachofthese j T R +1 j AddSubject commandsactivatesa NewSubject r attribute. Iftheinitialroleofthenewsubjectis r 0 ,thenthecorresponding AddSubject commandactivatestheattribute NewSubject r 0 Lemma7 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat:

PAGE 71

61 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethan N G ( S )GrantRight commands,where N G ( S )= 7( j T R j +1)( j T j +2)( j T j + j R j +2) Proof Weareinterestedonlyinthose GrantRight commandsthatgrant ADDSUBJECT,CREATEROLE,CREATEOT,GRANTRIGHT,ADDROLEBINDING ,and CHANGEOT rightsbecause: 1.BythedenitionofaccessrightleakproblemfortheDCS-A Cmodel, grantingsomerolearight 0 thatisnotoneofthesixteenDCS-ACsystem rightsor (therightweareinterestedin)doesnotaecttheaccessrig htleak problem. 2.Bylemma2,weareignoringallrevocationanddeletioncom mandsandby lemma3,wecanignoreall AddObject,AddAccess, and ChangeDP commands. Sincewearenotexecutingthesecommands,weneednotexecut e GrantRight commandsthatallowrolestoexecutethesecommands. Applyinglemmas2,3,5,and6,wecanconstructasequenceofc ommands 1 from thatresultsinaleakingstateandcontains: norevocationordeletioncommands no AddObject,AddAccess, or ChangeDP commands nomorethanone CreateRole andone CreateOT command nomorethan j T R j +1 AddSubject commands. Leteach GrantRight( r;r 1 ;t;ot; 1 ) commandactivatethe HasRight r 1 ;ot; 1 ;t attribute.Weknowthat 1 hastobeoneofthesevenrightsidentiedabove. Furthermore,ifa GrantRight command, j ,activatesaattributethatwasactive intheinitalstate S orwasactivatedbyanearliercommand i ,wecanignorethis commandsincetherearenorevocationordeletioncommands. Weconstructanew sequenceofcommands 0 from 1 thatdoesnotcontainany GrantRight command thatactivatesanalreadyactiveattribute.Sincewearethr owingawayonlythose

PAGE 72

62 commandsthataremeaninglessinthecontextofaccessright leak, 0 willstill resultinaleakingstate. Therefore,thenumberof GrantRight commandsin 0 isnomorethanthe numberof HasRight r 0 ;ot 0 ; 0 ;t 0 attributes(activeorinactive).Weknowthat: numberofpossiblevaluesfor r 0 is j T R j +1 numberofpossiblevaluesfor ot 0 is j T j +2 1 numberofpossiblevaluesfor 0 is7. numberofpossiblevaluesfor t 0 is j T j +2+ j R j (since t 0 2 T [ R ). Let S 0 S 0 .Thismeansthatthenumberof HasRight attributesin S 0 isnomore than7( j T R j +1)( j T j +2)( j T j +2+ j R j ). Therefore,thenumberof GrantRight commandsin 0 isnomorethan7( j T R j + 1)( j T j +2)( j T j + j R j +2). Lemma8 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethan N R ( S )AddRoleBinding commands,where N R ( S )=( j T R j +1)( j SUB j + j T R j +1) Proof Applyinglemmas2,3,5,6,and7,wegetanewsequenceofcomma nds 1 from whichalsoresultsinaleakingstate. Now,each AddRoleBinding( r;s;r 1 ) commandactivatesthe CanBind s;r attribute. Weconstructanewsequenceofcommands, 0 byremovingall AddRoleBinding 1 Wecancreateonenewroleandonenewobjecttype.Since T R T ,intheresultingstate, j T 0 j canbeupto2morethan j T j

PAGE 73

63 commandsthatactivateaattributethatwasalreadyactivei n S orwasactivated byanearliercommandin 0 Therefore,thenumberof AddRoleBinding commandsin 0 isnomorethanthe numberof CanBind attributesinthatinstanceofDCS-AC.Moreover, 0 doesadds nomorethanonenewroleandnomorethan j T R j +1newsubjects(bylemmas5 and6respectively). Therefore,thenumberof AddRoleBinding commandsin 0 isnotmorethan ( j T R j +1)( j SUB j + j T R j +1). Sinceweareremovingonlythose AddRoleBinding commandsfrom 1 thatdo notchangethestateofthesystem, 0 willalsoresultinaleakingstate. Denition An enablercommand isacommandthatactivatesacurrentlyinactive attribute.Therefore,forastate S Enabled ( S )isthesetofinactiveattributesfor whichanenablercommandexists.Denition Foragivenstate S ,wesaythatasequenceofcommandsismonotonic ifandonlyifthesequencecontainsonlyenablerand ChangeOT commands Corollary9 Foragivenstate S ,right ,andobject o ,ifthereexistsasequence ofcommands thatresultsinaleakingstate,thenthereexistsasequence of commands 0 thatismonotonicandresultsinaleakingstate. Lemma10 Foragivenstate S ,thesetofcommandsthatactivatetheattributesin Enabled ( S ) canbeexecutedinanyorderandtheresultingstatewillbeth esame. Proof Let ( n )bethepropositionthatforasequenceof n commands (= 1 ; 2 ;:::; n )thatactivate n enabledattributes,foranypermutation ofthe commands 1 ; 2 ;:::; n ,( S S ) ) ( S S )where isthepermuted sequenceofthecommandsin BASECASE: n =2(Thereareonlytwopermutations,1 ; 2and2 ; 1) = 1 ; 2 .Let 0 = 2 ; 1

PAGE 74

64 Let 1 activatetheattribute 1 and 2 activate 2 .Let S S and S 1 S 0 S isthestateobtainedastheresultofaddingtheattributes 1 and 2 to S and S 0 istheresultofaddingthesametwoattributesto S ) S = S 0 .Hence (2)istrue. InductionStep:Assumethat ( k )istrueforall k (2 k
PAGE 75

65 Case2: 0 n 6 = n Let ( n )= 0 j (1 j
PAGE 76

66 8 r 2 T R add NewSubject r to InactiveAttributes 8 r 2 T R ; 8 ot 2 T; 8 0 2 R; 8 t 2 ( T [ R ) if HasRight r;ot; 0 ;t = 2 Active ( S )thenadditto InactiveAttributes 8 s 2 SUB; 8 r= 2 f r ( s ) ; add CanBind s;r to InactiveAttributes Theabovestepcanbecompletedin O ( N ( S 0 ))time.Oncewehaveidentiedthe inactiveattributes,wecanproceedtothenextstep. SaturationStepWewillnowsaturatetheinstance,i.e.,activateeveryattr ibutethatcanbe addedtillnothingmorecanbeadded.Startingfrom S 0 ,weexecutealltheenabled commandsinthecurrentstate( S i )toreachanewstate( S i +1 )andrepeatthisstep tillnomoreattributescanbeactivated. Bylemma10,wecanexecutethecommandsthatenabletheattri butes in Enabled ( S i )inanyorder.Weexecutethemalltakingcareofthefollowin g book-keepingsteps: Ifthe NewRole attributeisactivated,then: 1.Forallsubjectscurrentlyinthesystem,addacorrespond ingattribute ( CanBind s;r new where s isthesubjectand r new isthenewrolecreated). 2.Forallobjecttypes,rights,andtargets,add HasRight r new ;ot; 0 ;t to InactiveAttrinutes Ifthe NewOT attributeisactivated,thenaddcorresponding HasRight attributes. Ifa NewSubject r 0 attributeisactivated,thenforallroles r 1 currentlyinthe systemotherthan r 0 ,add CanBind s new ;r 1 to InactiveAttributes ,where s new isthenewsubjectadded. Removeallattributesthatareactivatedfrom InactiveAttributes oncethe enablingcommandisexecuted. Repeattheabovesteptillwereachastate S s forwhich Enabled ( S s )= ; Atthispointthesystemissaturatedandwecannotactivatea nynewattribute.

PAGE 77

67 Sincethereareatmost N ( S 0 )attributes,thissteptakes O ( N ( S 0 ) 2 )time.Wenow proceedtothenextstep. TypeCheckingStepLet S s =( A 0 ;R 0 ;T 0 ;T 0 R ;SUB 0 ;OBJ 0 ;f 0 o ;f 0 r ).Now,wecantacklethe ChangeOT commandasfollows:Werstidentifythesetof leakingtypes LT andthencheckif o canbechangedtoanyofthesetypes. LT = f ot j ot 2 T 0 ^ S s ;;ot S 0 ;;f o ( o ) 6 = ;g Wecanidentifytheelementsoftheset LT in O ( j T jj SUB jj T R jj R j )time. Oncewehaveidentiedtheelementsof LT ,wecancheckifthetypeof o can bechangedtoanyofthesetypesbycreatinga Typechange graph, G =( V;E ) where G isadirectedgraphsuchthat V = T 0 T 0 R and E = f ( ot 1 ;ot 2 ) j ot 1 ;ot 2 2 T 0 ^9 r 2 T 0 R suchthat( CHANGEOT;ot 1 ;dp ) 2 A 0 [ r;ot 2 ] g Thatis,thenodesin G correspondtoobjecttypesin S s andthereisanedgefrom ot 1 to ot 2 ifsomerolecanchangetheobjecttypeofanobjectfrom ot 1 to ot 2 Now,theproblemofdecidingiftheobjecttypeof o canbechangedtooneof the leakingtypes isreducedtoagraphreachabilityproblemwhichcanbesolve d byperformingadepthrstsearchstartingfrom f o ( o )(theobjecttypeof o inthe initialstate)andcheckingifthecurrentnodeisin LT .Ifoneofthetypesin LT canbereachedfrom f o ( o ),thenthereisasequenceofcommandsthatcanleadto aleakingstateelsetheredoesnotexistasequenceofcomman dsthatresultina leakingstate. Thegraphcanbeconstructedin O ( j T j 2 )timeandthegraphtraversalalso takesthesameamountoftime.Thetypecheckingsteptakes O ( j T jj SUB jj T R j j R j )time.

PAGE 78

68 Ofthethreestepsmentionedabove,thesaturationsteptake sthemostamount oftimeandhencetheARLproblemcanbedecidedin O ( N ( S ) 2 )time. 5.5 Summary Inthischapter,werestrictedtheDCS-ACmodelandsawhowto decidein polynomialtimewhetheragivenstatecouldresultinaleaki ngstatebyexecuting anarbitrarysequenceofcommandsifvotingisdisallowed.W eassumedmonotonicityandprovedthatthereisapolynomialupperboundon thenumberof meaningfulcommands(i.e.,commandsthatwhenexecutedres ultinachangeof state).Usingthis,weconstructedadirectedstategraphwh ereeachnodeofa graphcorrespondstoastateandtwonodesareconnectedifth ereisacommand whichwhenexecutedonthestartingstateresultsintheendi ngstate. Wethenidentiedthosestateswhichresultinaleakandifth ereisapath fromthenodecorrespondingtothestartingstatetoanodeco rrespondingtoone oftheleakingstates,thenthesystemcanleaktheright.The commandsthatwill resultinaleakingstateisthesequenceofcommandsthatcor respondtotheedges alongsuchapath.Hencetheaccessrightleakproblemforthi srestrictedversionof theDCS-ACisdecidableinpolynomialtime.Inthenextchapt er,wewillseehow tosolvethisproblemifvotingisallowed.

PAGE 79

CHAPTER6 TRUSTANDVOTING 6.1 Introduction InthischapterwewillanalyzethesafetyoftheDCS-ACmodel wheresubjects areallowedtovote.Sincewecannotdeterministicallypred icthowthesubjectswill votewewillapproachtheproblemfromadierentangle.Weas signanumerical value, trust-level ,toeachsubjectwhichrepresentstheamountofresourcesa maliciousentityneedstoexpendinordertomakethesubject voteagainstthe bestinterestsofthegroup.Wewillidentifythreesimpleap proachesonhow subjectscanbe\turned"andanalyzetheaccessrightleakpr oblembasedonthese approaches. 6.2 TrustandTrust-Worthiness Oneofthekeyquestionsinanyvoteis\Howmuchcanwetrustth evotersto maketherightdecision?".Therearemanyaspectsinvolvedi n trust ,someofwhich areidentiedbelow: understandingofandbeliefinthemissionofthegroup sounddecision-makingprocess rationalbehavior susceptibilitytoblackmailorbribery protectionofidentity Dierentgroupsgivedierentweight-agestotheseandothe raspectsoftrust. Basedonthese,weassigna trustlevel toeachsubject s denotedby ( s ),whichis theamountofresourcesrequiredtoturnthesubject s .Ourmainconcernhereis 69

PAGE 80

70 thesusceptibilityofthesubjectstomakeawrongdecision. Bywrong,wemeana decisionthatisnotinthebestinterestsofthegroup.Thesu bjectmightdecideto dothewrongthingbyintention(needlesstosay,ourtrustle velinsuchaperson wouldbelow).Weassumethatweknowthetrustlevelofallsub jectsinthegroup andthatthistrustlevelisconstant.Forthesakeofsimplic ity,wewillassumethat eachsubjectinthesystemhasauniquetrustlevel. ( s 1 )= ( s 2 ) s 1 = s 2 Notethatwedonottalkabouthowthetrustlevelsareassigne dasthismayvary fromgrouptogroupdependingonthegroupproirities.Wesho uldconsiderallthe factorsmentionedaboveandotheraspectsthatthegroupmig htfeelimportant. Wecoulduseareputation-basedtrustmanagementschemelik ethemodeldened byShmatikovandTalcott[57]orafeedback-basedschemesim ilartotheoneused ineBay[58].Inoursafetyanalysis,wewillassumethateach subjecthasaunique trust-levelthatisassignedoutsideoftheDCS-ACandiscor rect. 6.2.1 ApproachingTrust Therearemanywaysoflookingattrustandsusceptibility.T hekeyideain hereistolookattrustlevelastheamountofresourcesneede dtomakeaparticular subjectorgroupofsubjectsvoteinamannerthatisagainstt hebestinterestsof thegroup.Withthisinmind,wewillnowlookatthreedieren tapproachesto analyzingsusceptibilitythroughtrustlevelsasdenedhe re. Ad-ApproachIntherstcase,ifsomeonecanmakeasubject s 1 makeadecisioninacertain way,thenthatpersoncanmakeanyothersubject s 2 makethesamedecisionin thesamewaywithnoadditionaleortif ( s 1 ) ( s 2 ).Wewillcallthisthe Advertisementapproach (ad-approach)sincewecanlookatthisaspayingforan advertisementwhichallthevoterswillsee.Iftheadisgood enoughtoconvince s 1

PAGE 81

71 then s 2 willalsobeconvinced.Wewilluse A ( s )todenotethetrustinasubject s underthead-approach.Itmustbenotedthatinthisapproach ,one\ad"willcover alldecisionsrequired. Pay-As-You-GoApproachItispossibletobribeorcheatthevoterstoturnonedecisio natatime.This meansthatmoreresourcesarerequiredtoconvincethesamev oterifhe/shegets toparticipateinanotherdecisiondowntheline.Wewillcal lthisthePay-as-you-go approach(P-approach)anduse P ( s )todenotethetrustinasubject s underthis approach. HonestPoliticianApproachInthewordsofformerU.S.senatorSimonCameron,\anhonest politician isonewhowhenbought,staysbought".Thekeyideabehindthi sapproachis theassumptionthatallthesubjectsare\honestpolitician s".Inthiscase, ( s )is theamountofresourcesthatsomeonehastoexpendtomake s 1 makeacertain decision(thatpersonhastoexpend ( s 2 )additionalresourcesto\turn" s 2 ).In addition,oncebought,thesubjectstaysboughtandnoaddit ionalresourcesare requiredifthesubjectgetstovoteonanotherdecisionlate r.Wewillcallthisthe HonestPoliticianapproach (H-approach).Wewilluse H ( s )todenotethetrustin asubject s undertheH-approach. HybridApproachTheapproachesmentionedaboveareverysimplisticandinre ality,amixture oftheseapproachesismorelikelytobeused.Thesethreeapp roachesprovidea startingpointfordiscussionandaremoreusefulinintrodu cingtheideasdiscussed here.Wehopetoextendthistomodelreal-lifeapproachesin thenearfuture.We willconcentrateonlyontherstthreeapproacheshere.

PAGE 82

72 6.2.2 DecisionTemplates Inordertoclarifyhowdecisiontemplateswork,letuslooka tasimpledecision template.Here,allvotesareweightedequallyandparamete rslikequorum,voting period,percentageofvotesrequiredfora yes voteareallpartofthetemplate. Eachsuchvotingtemplateisrepresentedbythetuple( V R ;k;q;t d ;y d )where, V R isasetofrolesthatcanparticipateinthevote, k isanumberbetween0and1whichrepresentstheratiobetween the minimumnumberof yes votesrequiredtopassandthetotalnumberof participatingvoters, q isanothernumberbetween0and1whichrepresentsthequorum (i.e.,ratio ofminimumnumberofvotersrequiredtoparticipateandthet otalnumberof voters), t d isthetimedurationoverwhichthevoteisactive(example:2 days),and, y d isthedefaultdecisionwhichisreturnedifthedeadlinehas passedandthe quorumhasnotyetbeenreached. Inaddition,thesetofdecisionpointers, DT ,alsocontainsan Always-Yes template ( d yes )whichalwaysreturns yes .Thereasonforthisisthatmanydecisionsdonot requireavote.Anexampleofthetemplateis( f Faculty;Staff g ; 0 : 5 ; 0 : 8 ; 2days ;N ). Inthistemplate,allsubjectswhocanbindtotherolesFacul tyandStacanparticipateinthevotewhichrequiresasimplemajoritywithat least80%voter turnout.Ifafter2days,thequorumisnotreached,aresulto f No isreturned.If aftertwodays,atleast80%ofthevotershavecasttheirvote s,thena Yes decisionisreturnedifatleasthalfthevotescastare yes votes,ifnotaresult No is returned.

PAGE 83

73 Inourmodel,eachsubjectgetstocastonevoteevenifhe/she canbindto morethanonerolein V R .Adiscussionoftheactualworkingofthevotingmechanismisbeyondthescopeofthisworkandwewillrestrictour selvestoabriefdescriptionofthelife-cycleofavote.Whenagroupdecisioni scalledfor,weinstantiateavote v basedonthetemplate. V =( E v ;Vote v ;Voted v ;T v ;k v ;q v ;default ) where: E v isthesetofalleligiblevoters Vote v isamappingbetweeneachsubjectandhis/hervoteinthedeci sion. Thepossiblevaluesare D (defer), Y (Yes), N (No),and, A (abstain) Voted v isthesetofalleligiblevoterswhohavecastavalidvote( Y;N; or, A ) T v isthedeadlineforthevotewhichisobtainedbyadding t d tothetimeof voteinitialization. k v isthevalueof k inthetemplate q v isthevalueof q inthetemplate default isthevalue y d ofthetemplate E v = f s 2 SUB j V R \ f r ( s ) 6 = ;g Vote v : E v !f Y;N;A;D g Voted v = f s 2 E v j Vote v ( s ) 2f Y;N;A gg Initially,sincenobodyhasvotedyet, 8 s 2 E v ;Vote v ( s )= D Whenaneligiblevoter, s ,castsavalidvote( Y;N; or, A ),his/hervoteis updatedin Vote v and s isaddedto Voted v .Whenthedeadline T v isreached,all newvotesarerejectedandadecisionisreached.

PAGE 84

74 Weidentifythefollowingsets: Y v = f s 2 E v j Vote v ( s )= Y g N v = f s 2 E v j Vote v ( s )= N g A v = f s 2 E v j Vote v ( s )= A g Werstcheckforthequorum, j Voted v j j E v j q v ifthisisfalse,wereturnthedefaultdecision.Ifeverysub jectwhovotedhas abstained,( j Y v j + j N v j =0),wereturnthedefaultdecision.Next,wecheckif enoughyesvoteshavebeencast. j Y v j j Y v j + j N v j k ifthisistrue,wereturnyesandwereturnnootherwise. 6.3 ARLProblemAndStates Sinceexcecutionofcertaincommandsisdependentonthesub jectswhoare allowedtovote,wehavetofactorourtrustinthesubjectswh iledecidingthe safetyofthesystem.Withthisinmind,weredenetheaccess rightleakproblem foraDCS-ACsystemwithvotingasfollows:Denition Foragivenstate S 0 ,object o ,right ,and,budget,theaccess rightleakproblem(ARL)isadecisionproblem,doesthereex istasequenceof commandsin S 0 withtrustlevellessthanthatresultsinaleakingstate. ARL f j9 suchthat S 0 S t and S t ;;f 0 o ( o ) S 0 ;;f o ( o ) 6 = ; and( ) g where( )isourtrustinthesequenceofcommands byapplyingoneofthe threeapproaches.

PAGE 85

75 Inotherwords,canamaliciousparty,withagivenbudget,co rruptenoughvoters toenableanunauthorizedsubjectaccesstoanobject. Let N v ( S 0 )denotethenumberofcommandsthatcanbeexecutedonthe initialstate S 0 andallitsdescendentstates.Weareonlyconcernedwiththe commands CreateRole CreateOT GrantRight AddSubject AddRoleBinding ,and ChangeOT (thisisduetoCorollary4).Asproveninthelemmas3,5,6,7, and8, thetotalnumberofsuchcommandsisbounded. N v ( S 0 ) 1+1+( j T R j +1)+ N G ( S 0 )+ N R ( S 0 )+( j T T R j +1) 4+ N G ( S 0 )+ N R ( S 0 )+ j T j Denition ForagivenDCS-ACsystemwithinitialstate S 0 ,wedenethesetof allpossiblereachablestates, c S 0 asfollows: c S 0 = f S j ( S = S 0 ) ( 9 suchthat S 0 S ^ S 0 2 c S 0 ) g Thesizeofthissetisdependentonthenumberofcommandstha tcanbeexecuted ontheinitialstateanditsdescendants.Eachstatecanbere presentedbya N v ( S 0 )bitnumberwhereeachbitcorrespondstoaparticularattrib ute.Thebitis1ifthe correspondingattributeisactiveinthatstateand0otherw ise. j c S 0 j 2 N v ( S 0 ) 6.4 TrustAnalysisofDCS-AC LetusnowprovethetractabilityoftheARLproblemforaDCSACsystem. Asmentionedearlier,wewillusethetrust-worthinessofsu bjectstodecideonthe trust-worthinessofthesystem. 6.4.1 StateGraph Wewillnowconstructadirectedgraph G S 0 =( V;E )whichcorrespondstoa DCS-ACsystemwiththeinitialstate S 0 (Wewillcallthisgraphthe StateGraph of S 0 ).Thesetofvertexesis V = c S 0 andthereisanedgefromvertex S i to S j

PAGE 86

76 labeled( ;r )if S j istheresultwhenasubjectboundtotherole r executesthe command in S i Sinceeachstatehasauniquesetofproperties,therecannot bemorestates thanthetotalnumberofpropertiesinanygivenpath. j V j = j c S 0 j 2 N v ( S 0 ) Inanygivenstate,wecannotexecutemorethan N v ( S 0 )commandsandeachof thesecommandscanbeexecutedbyatmost j T R j roles. j E jj V jj T R j N v ( S 0 ) j T R j N v ( S 0 ) 2 N v ( S 0 ) Ifweuseanadjacencylist,wecanconstructthegraphin O ( j E j ).Therefore,the graphcanbeconstructedin O ( j T R j N v ( S 0 ) 2 N v ( S 0 ) )time. Let S L denotethesetofallleakingstates. S L = f S i 2 c S 0 j S i ;ot; S 0 ;f o ( o ) ; 6 = ;g Asmentionedinthepreviouschapter,wecanidentifytheele mentsof S L in O ( j V jj T jj T R jj SUB jj R j )time. BeforelookingatthethreeapproachestotrustfromtheDCSACpointof view,letusdeneafewusefulsets.Foradecision d =( V R ;k;q;y d ;t d ),let W ( d ) bethesetof ( d )weakest(intermsofsusceptibility)voters.Thesevoters arethe mostlikelytovoteagainstthebestinterestsofthegroup. W ( d )= f s j s 2 V ( d ) ^ @ s 1 ;s 2 ;:::;s ( d ) 2 V ( d )suchthat i 6 = j s i 6 = s j ^8 i 2 [1 ; ( d )] ( s i ) < ( s ) g

PAGE 87

77 Foracommand ,let W c ( )denotethesetofvotersthataremostlikelytovote againstthebestinterestsofthegroup. W c ( )= W ( d ) where d isthedecisionthatguardsthecommand.Moreover,somesubj ecthas toissuethecommandinordertoexecuteit.Therefore,ourtr ustinacommand hastoincludeourtrustintherolethatcanissuethecommand .Let r ( r )denote ourtrustinarole r .Ourtrustinaroleisthesameasourtrustintheleast trustworthysubjectthatcanbindtothatrole. r ( r )= min f ( s ) j s 2 SUB and r 2 f r ( s ) g Needlesstosay,ourtrustinthedecisionpointer d yes is0. 6.4.2 Ad-Approach Let A ( d )denoteourtrustlevelinadecision.Inad-approach, A ( d ),isthe maximumtrustlevelofallthevotersin W ( d ). A ( d )= max f A ( s ) j s 2 W ( d ) g Let d bethedecisiontemplatethatguardsacommand .Iftherightthatguards isenabled,thenwecantrust onlyasfaraswecantrust d .Let A ( )denote ourtrustlevelinacommand .Here,wearelookingatthecommandbyitself withnoprior\history".Theremaybemorethanonerolethatc anissuethe command.Let r l betheleasttrustworthyofalltherolesthatcanexecutethe command. A ( )= max ( A ( d ) ;r ( r l ))

PAGE 88

78 Now,foragivensequenceofcommands (= 1 ; 2 ;:::; n ),let A ( )denotethe trustlevelin usingthead-approach. A ( )= A ( i )suchthat 8 j 2 [1 ;n ] ; A ( j ) A ( i ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate,we havetondapathfrom S 0 to S L thathastheleast A value.Weachievethisby doingamodieddepthrsttraversalonthegraph. FunctionDFT( v ) //Thearray visited []isglobalandinitiallysettofalse //Thevalue MinCost A ( S 0 )isinitially 1 //Thestackisinitiallyempty. 1. visited [ v ]= true 2.if v = S L then (a)let bethesequenceofcommandsinthestack (b) c = A ( sigma ) (c)if( c 2 ARL MinCost A ( S 0 ) Theabovedepth-rsttraversalcanbecompletedin O ( j E j )time.HencetheARL problemusingtheAd-approachcanbesolvedin O ( j T R j 2 N v ( S 0 ) )time.

PAGE 89

79 6.4.3 Pay-As-You-GoApproach Let P ( d )denoteourtrustlevelinadecision.Inthisapproach, P ( d ),isthe maximumtrustlevelofallthevotersin W ( d ). P ( d )= X s 2 W ( d ) P ( s ) Let d bethedecisiontemplatethatguardsacommand .Iftherightthatguards isenabled,thenwecantrust onlyasfaraswecantrust d .Let P ( )denote ourtrustlevelinacommand .Here,wearelookingatthecommandbyitself withnoprior\history".If r l istheleasttrustworthyrolethatcanissuethe command P ( )= P ( d )+ r ( r l ) Now,foragivensequenceofcommands (= 1 ; 2 ;:::; n ),let P ( )denotethe trustlevelin usingthethisapproach. P ( )= X i 2 P ( i ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate, wehavetondapathfrom S 0 to S L thathastheleast P value.Weachievethis byusingthesingle-sourceshortestpathalgorithmstartin gfrom S 0 .Foreachedge ( S i ;S j ),theedgeweightis P ( )where isthelabeloftheedge. Lettheminimumcosttoreach S L be MinCost P ( S 0 ). 2 ARL MinCost P ( S 0 ) Hereagain,thesinglesourceshortestpathtakes O ( j E j )time(sinceweareusing adjacencylists)andhencetheARLproblemcanbesolvedusin gtheP-Approachin O ( j T R j 2 N v ( S 0 ) )time.

PAGE 90

80 6.4.4 HonestPoliticialApproach IntheHonestPoliticalapproach,asubjectonce\bought"st aysbought.There aretwoproblemswithapplyinganalgorithmsimilartotheon esusedfortheother approaches.Considerthetwodecisions d 1 and d 1 andtwosubject s 1 and s 2 such that:(i) s 1 and s 2 arebothvalidvotersfor d 1 and s 2 isavalidvoterfor d 2 ,and(ii) s 1 isamongthepotentiallyweakvotersin d 1 while s 2 isnot. s 1 ;s 2 2 Voters ( d 1 )and s 2 2 Voters ( d 2 ) s 1 2 W ( d 1 )and s 2 = 2 W ( d 1 ) 1.If s 2 2 W ( d 2 ),i.e., s 2 isamongthepotentiallyweakvotersin d 2 ,theninstead ofspendingresourcesonboth s 1 and s 2 ,amaliciousentitycan\buy"only s 2 andstillgetboththedecisionsthussavingontheresources requiredtobuy s 1 2.If s 2 = 2 W ( d 2 )butthereexistsasubject s 3 2 W ( d 2 )suchthat H ( s 1 )+ H ( s 3 ) > H ( s 2 ),thenitwouldbecheapertobuy s 2 insteadofboth s 1 and s 3 Theabovetwoscenarioscanbeextendedtoanynumberofsubje ctsandany numberofdecisionssuchthatreplacingasinglesubjectcan leadtoacascading eectonotherdecisionsifthesubjectbeingreplacedisamo ngtheweakvotersin theotherdecisions. Aswecansee,themainproblemiswithvoterswhocanparticip ateinmore thanonedecisioninasequenceofdecisions.Oursolutionto thisproblemisvery simple.Ifasubject s 1 withatrustlevelof H ( s 1 )participatesin n ( < j j )decisions inasequenceofcommands ,thenlet H ( s 1 )denotethecostperdecisioninthe sequence. H ( s 1 )= H ( s 1 ) n

PAGE 91

81 Lettheset V ( )denotethesetofallvotersinallthedecisionsin V ( )= [ i 2 Voters ( d i )where d i isthedecisionthatguards i Let W s ( )denotetheminimalsetofvotersrequiredtogetallthedeci sionsin Letusnowlookatanalgorithmtondthisset. Function W s ( ) //Returnstheminimalsetofvoters//Initially W s isanemptyset 1.sortallsubjectsin V ( )accordingtotheir H 2.Foreach i in (a)Let d i denotethedecisionguarding i (b)Let count bethenumberofvotersin i alreadybought. count = j Voters ( d i ) \ W s j //Wenowhavetond ( d i ) count eligiblevoters (c)while count< ( d i ) i.Find s 2 Voters ( d i ) W s withsmallest H ii.Add s to W s iii. count = count +1 3.Return W s Now,let H ( )denotethetrustlevelin usingthisapproach. H ( )= X s 2 W s ( ) H ( s ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate,we havetondapathfrom S 0 to S L thathastheleast H value.Weachievethisby usingtheDFTalgorithmgivenabove(wecalculate H and MinCost H insteadof A and MinCost A 2 ARL MinCost H ( S 0 )

PAGE 92

82 Weknowthatthelengthofthelongestpossiblesequenceis N v ( S 0 ).Wealso knowthatthemaximumnumberofvotersthatcanparticipatei nadecisionis j SUB j .Hence,wecanndthe H foranysequenceofcommandsin O ( j SUB j N v ( S 0 ))time.Therefore,wecandecidetheARLproblemusingtheHapproachin O ( j SUB j N v ( S 0 ) j T R j 2 N v ( S 0 ) )time. 6.5 Summary InthischapterwelookedatthesafetyanalysisoftheDCS-AC modelwith voting.Weassumedthateachsubjecthasanumerical trust-level andintroduced threeapproachestotrustandsuseptibilitynamely,Ad,Hon estPoliticianand Pay-As-You-Go.Wethensawhowtodeterminethetrustinavot e,acommand andasequenceofcommandsbasedoneachofthesethreeapproa ches.Withthis asbuildingblocks,weanalyzedthesafetyoftheDCS-ACmode lwithamodied accessrightsleakproblem. ThekeyideaintheAd-approachisthatifamaliciousentityc anconvincea subject, s ,tovoteinamannerthatisnotinthebestinterestsofthegro up,then thatentitydoesnotneedanyadditionalresourcestoconvin ceanothersubject whosetrustlevelislessthanthatof s .InthePay-As-You-Goapproach,each subjecthasaspecicamountofresourcesrequiredtomakehi m/hervoteina mannerthatisnotinthebestinterestsofthegroupandthema liciousentity hastoexpendadditionalresourcesforeveryothersubjects andalsoforthesame subjectifhe/sheisrequiredtovoteagaininanotherdecisi on. ThemostcomplexofthethreeapproachesistheHonestPoliti cianapproach, inwhich,asubjectis\bought"fortheentiresetofdecision s.Thiscomplicates thesafetyanalysissinceamaliciousentityisbetterospe ndingresourcesona moreexpensivesubjectwhocanparticipateinmanydecision sasopposedtoalarge numberoflesstrustworthysubjecteachofwhomcanparticip ateinonedecision.

PAGE 93

83 Inordertosolvethisproblem,welookedatcostperdecision whiledecidingthe leastexpensivesetofvoters. Ineachofthesethreeapproaches,weconstructadirectedgr aphwhichwe callstategraphandusegraphtraversalalgorithmstosolve theaccessrightleak problem.Thereisacombinatorialexplosionofthenumberof statesandweproved thedecidabilityoftheARLproblemineachofthesethreeapp roachesbyproviding exponentialtimealgorithms.

PAGE 94

CHAPTER7 NEXTSTEPS Themodelaspresentedispowerful,rexibleandscalable.Ho wever,more workneedstobedoneinordertomakethismodelmodelreal-li fepolicies.Some oftheseareenhancingthecommandsinthemodel,extendingt hemodelitselfto allowsubject-to-objectprivilegedenitions,incorpora tingarolehierarchyand time-limitedaccessrights.Asmentionedearlier,amajorf eatureoftheDCSmodel istheuseofdecisiontemplateswhichcanprotectagainstsi nglemalicioususer attacks.Furtherworkneedstobedoneinanalyzingmulti-us ercollusionattacks. 7.1 EnhancingDCSCommands Therearesomeadditionsthatcanbedonetoimprovethemodel .Thecommandsasdescribedhereareallmono-operational(i.e.,per formonlyoneprimitive operation).Inmanycases,thesubjectcreatinganewobject hassomespecial rightswithrespecttothatobject,i.e.,thecreatorhasthe righttoread/writethe objectorgrantrightstoothers.Whilesomeonehasthe GrantRight privilegefor objectsofthattype,thisissueismorecriticalforcreatio nofnewrolesandobject types.Ifsomeonecreatesanewroleorobjecttype,theusabi lityofthisnewroleor objecttypeisseverelyrestrictedifnoonehastherighttoa llowsubjects/objects tobindtothatrole/objecttype.Thereforeanadditionalop erationneedstobe performedthatallowsthecreator'srolesomebasicrights. Thesafetyanalysisneedstoberevisitedsincetherolesand objecttypeshave pedigreeandwewillhavetofactorthisintotheanalysis.Ho wever,theresulting systemwouldbemoreusable. 84

PAGE 95

85 7.2 SpecialRelations Wewouldliketobeabletospecifysubject-to-objectlevela ccessrights,for example,eventhoughallprogrammershavetherighttoreada nycode,onlythe programmerwhowroteaparticularclasshastherighttomodi fyit.Wecanimplementthisbycreatinganewobjecttypeoranewroleforeachcl ass/programmer. Thisisinecientandasimplerwayistouse SpecialRelationships .Thesearea mappingfrom(subject,object)pairstoroles.( f s : SUB OBJ T R ).Wecan denearole ClassWriter andspecify f s ( programmer;class )= f ClassWriter g foreachclass.Now,eachtimeanaccessrequestismade,wesh ouldcheckforany specialrelationsbetweenthesubjectandtheobjectbefore checkingfortherole andobjecttype(thereasonbeing,specialrelationsareusu allymore\powerful" thanregularrolesforthatparticularobject).Thisclearl ychangesthedenitionof allthecommandsandthesafetyanalysisbutprovidesaveryu sefulwaytospecify ner-grainedaccesscontrol. 7.3 RoleHierarchy OneofthemajordierencesbetweentherolesasusedintheDC Smodel andRBACis rolehierarchy .Wecanimplementrolehierarchybymaintaininga partialorderingoftherolesintheformofadirectedgraph, G R =( V;E )where V T R and( r 1 ;r 2 ) 2 E ifandonlyif r 1 inheritsalltherightsfrom r 2 .Whenan accessrequestismade,werstcheckforspecialrelations, failingwhichtherights oftheuser'sroleischecked.Ifthisfails,abreadthrstse archisperformedon G R withthemodecorrespondingtotheuser'sroleasthestartin gpoint.Ateachnode visited,thecorrespondingroleischeckedfortherighttop erformtherequested access.Weusebreadthrstsearchinsteadofdepthrstsear chsinceroleshigher uponthehierarchyaremore\powerful"thanthosefurtherdo wnthegraph.It mightbeusefultoconstraintheroleorderingtobeacyclicf orsecuritypurposes. Thiscanbeensurediftherolehierarchycanbespeciedonly whentheroleis

PAGE 96

86 denedandcannotbechanged.Thisistoorigidandcanhurtth eutilityofthe model.Therefore,wecanallowthehierarchytobechangedan ytimebutthegraph couldbecheckedforcyclesbeforecommittingthechange.Si ncetherolegraphis notlikelytochangefrequently,thisisanacceptableoverh eadonperformance.The additionofrolehierarchyincreasestheoverheadwhilesea rchingforalltheusersin arole 1 7.4 Use-CasesandScenarios Oneofthemostimportantstepsinprovingtheusabilityofth emodelisto identifyvariousscenariosandshowhowthismodelcanbeuse dthere.Forexample, wecanmodeltheCISEdepartmentintermsofsubjects,roles, objects,etc.and showhowwecanusetheDCSmodel(OnlyPh.D.candidatescanre gisterfor doctoralresearchcreditsandaPh.D.studentcanbindtothe Ph.D.candidaterole ifhis/hersupervisorycommitteechairnominateshim/hera ndallthemembers ofthecommitteeagree).Oneotherscenariowecanconsideri stheoperationsof alargeorganizationlikeIEEE.TheideaistoshowhowtheDCS modelcanbe usedinthesescenarios,startingfrombootstrappingthesy stemtogettingitfully functional. 7.5 Multi-UserCollusionAttacks TheuseofdecisiontemplatesmakestheDCSmodelverypowerf ulandhelps minimizetheroleofthelocaldomainsystemadministrators .Thisalsoopensupan interestingareaofresearch,multi-usercollusionattack s.Foragivenstateofthe system,ifagroupofsubjectswanttotipavote(withagivend ecisiontemplate, dp 1 )intheirfavor,andtheytrytodosobyallowingsomeoftheir buddies to bindtosomeroleswhichparticipateinthatvote,howmany AddRoleBinding 1 Wemayhavetondthelistofalluserswhocanbindtoarolefor votingand noticationpurposes.

PAGE 97

87 commandsdotheyneed?Ifthe AddRoleBinding commandsrequireanothervote (say, dp 2 ),theywillhavetobeabletocarrythosevotesinordertoget afavorable resultfor dp 1 .Thequestionis,foranygiven dp 1 and dp 2 ,theminimumnumberof \conspirators"requiredtowinthevote dp 1 istheminimumnumberrequiredtowin dp 2 .Amorecomplexcaseiswhenyouneedtocontroltwovotes, dp 2 and dp 3 to win dp 1 7.6 Time-LimitedAccess Anotherusefuladditionis Time LimitedAccess ( TLA ) 2 .Insteadof returningasimpleyes/noanswer,thedecisionpointercoul dreturnthetimefor whichtheaccessisvalid.Iftheaccessisdenied,thenitret urnsazeroelseit returnsthetimeforwhichtheaccessisvalid.Duringthatti me,theuserisgranted accesstotheobjectwithoutstartingthedecision-makingm echanism.Thisisvery usefulfor\proxies"orsubstitutes.Forexample,iftheuse r Alice whocanbindto therole Instructor isleavingtownforaweek,shecanallow Bob (boundtorole TA )totemporarilybindtotherole Instructor .Wecanalsocreateanewrole sub Instructor withasubsetoftherightsof Instructor .Forexample, Bob can notassigngradestothestudents.InordertoimplementTLA, weneedaseparate datastructurethatstoresthetimeperiodofvalidity.TheT LAstructureshould eitherperiodicallyremoveexpiredentriesorcheckforval idityeachtimeanaccess isrequested.Thisagainmightincreasetheturn-aroundtim eforanaccessrequest butontheotherhand,itcanbeveryusefulsinceitcanhelpav oidfrequentcallsto timeconsumingdecisionpointers. 2 TLAcouldalsostandforThree-LetterAcronym

PAGE 98

CHAPTER8 CONCLUSION TheaccesscontrolmodeldescribedhereisdesignedfortheD istributed ConferencingSystemversion2(DCSv.2).However,thismode lcanbeusedin anydistributedsystemthatrequireshighlyavailableacce sscontrolservicesand userdrivendecisionmakingcapabilities.Wehaveformally speciedthemodel andanalyzeditsvariousadvantageswithrespecttoexistin gmodels.Wehavealso providedalgorithmstomapastateinaDCSsystemtoanequiva lentHRUstate and viceversa andprovedthattheaccessrightleakageproblemisdecidabl einNP time.Thesoftwareprojectexampleillustratestheusefuln essofthismode.Asseen inchapterfour,thismodelsatisesmanyinterestingprope rtiesofaccesscontrol systemsandsupportsuser-denedvotingtemplates.Thepre senceofdecision templatesallowsthemembersofthegrouptodecideontheiro wngrouppolicies andvoteonimportantdecisions.Thisdemocraticapproache nsuresautonomyfor thegroupsandprovidesgreaterrexibilityintermsofacces scontrol. Wehaveshownthatthemodelisprovablysafeintermsoftheac cessrights leakproblem.Sincesomeoftheaccesscontroldecisionsare madethroughvoting, thesecurityofthesystemdependsonourtrustinthevoters. Thisleadsustothe threeapproachestotrustthatarementionedhere.TheAd-Ap proachissimplistic andtheanalysisisverystraightforward.ThePay-As-You-G oapproachisslightly morecomplicatedandtheHonest-Politicianapproachisthe mostdicultofthe threetoanalyze.Inallthreeapproaches,wereducedthepro blemtosomeformof graphreachabilityandhaveprovidedalgorithmicsolution stothesame. Thistypeofanalysiscanhelpusprepareagainstmulti-user collusionattacks andisheavilydependentonaccuratelyassigningtrust-lev elstoallthesubjects. 88

PAGE 99

89 Inreality,ahybridofthesethreeapproachesislikelytobe usedandthiswork providesastartingpointforfurtherworkinthisarea.Inco nclusion,themodel presentedhereisscalable,useful,provablysecure,andve ryrexible.

PAGE 100

REFERENCES [1]B.W.Lampson,\Protection,"in Proceedingsof5thPrincetonSymposiumon InformationSciencesandSystems .Princeton,1971,pp.437{443. [2]G.ScottGrahamandPeterJ.Denning,\Protection{princ iplesandpractice," in ProceedingsofSpringJointComputerConference .AFIPS,1972,pp. 417{429. [3]StevenJ.Greenwald,\Anewsecuritypolicyfordistribu tedresourcemanagementandaccesscontrol,"in Proceedingsofthe1996WorkshoponNew SecurityParadigms .1996,pp.74{86,ACMPress. [4]MarkusLorchandSethProctorandRebekahLeproandDenni sKafuraand SumitShah,\FirstexperiencesusingXACMLforaccesscontr olindistributed systems,"in Proceedingsof2003ACMWorkshoponXMLsecurity .2003,pp. 25{37,ACMPress. [5]IanFosterandCarlKesselmanandGeneTsudikandStevenT uecke,\A securityarchitectureforcomputationalgrids,"in Proceedingsofthe5thACM ConferenceonComputerandcommunicationssecurity .1998,pp.83{92,ACM Press. [6]M.WebbandD.L.WilsonR.E.Newman-WolfeandC.L.Ramire zandH. PelimuhandiramandM.Montes,\Abriefoverviewofthedcsdi stributed conferencingsystem,"in ProceedingsofSummerUsenixConference ,Nashville, TN,1991,USENIX,pp.437{452. [7]AndrasBelokosztolszkiandKenMoody,\Meta-policies fordistributed role-basedaccesscontrolsystems,"in Policy2002:IEEE3rdInternational WorkshoponPoliciesforDistributedSystemsandNetworks ,2002,pp.106{ 115. [8]AnekVorapanya, Large-ScaleDistributedServices ,Ph.D.dissertation, UniversityofFlorida,2000. [9]JamesGoslingandBillJoyandGuyL.SteeleJr.andGiladB racha, The JavaLanguageSpecication ,Addison-WesleyProfessional,Boston,MA,third edition,2005. [10]HerbertSchildt, Java:TheCompleteReference,J2SE5Edition ,McGraw-Hill OsborneMedia,2004. 90

PAGE 101

91 [11]AshishBhalani,\Implementationofconferencecontro lserviceindistributed conferencingsystem,"M.S.thesis,UniversityofFlorida, 2002. [12]SwatiShukla,\Noticationservicesinadistributedc onferencingsystem," M.S.thesis,UniversityofFlorida,2000. [13]AmitV.Date,\Implementationofdistributeddatabase andreliablemulticast fordistributedconferencingsystemversion2,"M.S.thesi s,Universityof Florida,2001. [14]RamezElmasriandShamkantB.Navathe, FundamentalsofDatabaseSystems Addison-Wesley,Boston,MA,1994. [15]MaydeneFisherandJonEllisandJonathanBruce, JDBCAPITutorialand Reference ,Addison-WesleyProfessional,Boston,MA,thirdedition, 2003. [16]LukeWellingandLauraThomson, MySQLTutorial1/e ,MySQLPress, Uppsala,Sweden,2004. [17]KorryDouglasandSusanDouglas, PostgreSQL ,Sams,Indianapolis,IN,2003. [18]AparnaKakarparti,\Decisionsupportservicefordist ributedconferencing system,"M.S.thesis,UniversityofFlorida,2002. [19]VijayManian,\Accesscontrolfordistributedconfere ncingsystem,"M.S. thesis,UniversityofFlorida,2002. [20]RavichandranAringunram,\Securecommunicationserv icesgambettatrustfor distributedconferencingsystem,"M.S.thesis,Universit yofFlorida,2002. [21]PhilipS.Yeager,\Adistributedlesystemfordistrib utedconferencing system,"M.S.thesis,UniversityofFlorida,2003. [22]VijayaRangadhamKomaragiri,\Motherofallconcurren teditorsversion2.0," M.S.thesis,UniversityofFlorida,2004. [23]CharlesP.Preeger, SecurityinComputing ,Prentice-Hall,Inc.,UpperSaddle River,NewJersey,1996. [24]D.BellandL.LaPadula,\Computersecuritymodel:Uni edexpositionand multicsinterpretation,"Tech.Rep.MTR-2997,MITRECorpo ration,1976. [25]K.J.Biba,\Integrityconsiderationforsecurecomput ersystems,"Tech.Rep. MTR-3153,MITRECorporation,1977. [26]E.EllmerandG.PernulandG.QuirchmayrandA.Tjoa,\Ac cesscontrolfor cooperativeenvironments,"in WorkshoponDistributedSystems,Multimedia, andInfrastructure,ACMConferenceonComputer-Supported Cooperative Work(CSCW'94). ,1994.

PAGE 102

92 [27]MichaelA.HarrisonandWalterL.RuzzoandJereyD.Ull man,\Protection inoperatingsystems," CommunicationsoftheACM ,vol.19,no.8,pp. 461{471,August1976. [28]R.S.Sandhu,\Thetypedaccessmatrixmodel,"in ProceedingsoftheIEEE SymposiumonSecurityandPrivacy ,Washington,DC,1992,pp.122{136, IEEEComputerSociety. [29]RaviS.SandhuandGurpreetS.Suri,\Implementationco nsiderationsforthe typedaccessmatrixinadistributedenvironment,"in Proceedingsofthe15th NIST-NCSCNationalComputerSecurityConference ,Baltimore,MD,1992, pp.221{235. [30]P.E.AmmannandRaviS.Sandhu,\Safetyanalysisforthe extended schematicprotectionmodel,"in ProceedingsofIEEESymposiumonResearchinSecurityandPrivacy ,Washington,DC,1991,pp.87{97,IEEE. [31]RaviS.Sandhu,\Theschematicprotectionmodel:Itsde nitionandanalysis foracyclicattenuatingschemes," JournalofACM ,vol.36,no.2,pp.404{432, 1988. [32]PatrickH.WoodandStephenG.Kochan, UNIXSystemSecurity ,Hayden Books,Indianapolis,1985. [33]leenFrisch, EssentialSystemAdministration ,O'Reilly&Associates,New York,1996. [34]DavidFerraioloandRichardKuhn,\Role-basedaccessc ontrol,"in Proceedings of15thNationalComputerSecurityConference ,Baltimore,MD,1992,pp. 437{443. [35]DavidF.FerraioloandJanetA.CuginiandD.RichardKuh n,\Role-based accesscontrol(rbac):Featuresandmotivations,"in Proceedingsof11th AnnualComputerSecurityApplicationConference ,NewOrleans,LA,1992, pp.241{48. [36]DavidF.FerraioloandRaviSandhuandSerbanGavrilaan dD.Richard KuhnandRamaswamyChandramouli,\ProposedNISTstandardf orrolebasedaccesscontrol," ACMTransactionsonInformationandSystemSecurity (TISSEC) ,vol.4,no.3,pp.224{274,2001. [37]RoshanK.Thomas,\Team-basedaccesscontrol(TMAC):a primitive forapplyingrole-basedaccesscontrolsincollaborativee nvironments,"in ProceedingsofthesecondACMWorkshoponRole-basedaccess control ,New York,NY,1997,pp.13{19,ACMPress.

PAGE 103

93 [38]Gail-JoonAhnandRaviS.Sandhu,\Role-basedauthoriz ationconstraints specication," InformationandSystemSecurity ,vol.3,no.4,pp.207{226, 2000. [39]StevenJonGreenwald, TheDistributedCompartmentmodelforResource ManagementandAccessControl ,Ph.D.dissertation,UniversityofFlorida, 1994. [40]IreneGreifandSunilSarin,\Datasharingingroupwork ,"in CSCW'86: Proceedingsofthe1986ACMConferenceonComputer-Support edCooperative Work ,NewYork,NY,1986,pp.175{183,ACMPress. [41]ClarenceA.EllisandSimonJ.GibbsandGailRein,\Grou pware:someissues andexperiences," Commun.ACM ,vol.34,no.1,pp.39{58,1991. [42]AdrianBullockandSteveBenford,\Anaccesscontrolfr ameworkformultiusercollaborativeenvironments,"in GROUP'99:ProceedingsoftheInternationalACMSIGGROUPConferenceonSupportingGroupWork ,NewYork, NY,USA,1999,pp.140{149,ACMPress. [43]JoergM.HaakeandAnjaHaakeandTillSchummerandMoham ed BourimiandBrittaLandgraf,\End-usercontrolledgroupfo rmationand accessrightsmanagementinasharedworkspacesystem,"in CSCW'04: Proceedingsofthe2004ACMConferenceonComputersupporte dcooperative work ,NewYork,NY,2004,pp.554{563,ACMPress. [44]HongHaiShenandPrasunDewan,\Accesscontrolforcoll aborativeenvironments,"in CSCW'92:Proceedingsofthe1992ACMConferenceon Computer-SupportedCooperativeWork ,NewYork,NY,1992,pp.51{58,ACM Press. [45]JoonS.ParkandJunseokHwang,\Role-basedaccesscont rolforcollaborative enterpriseinpeer-to-peercomputingenvironments,"in SACMAT'03: ProceedingsoftheEighthACMSymposiumonaccesscontrolmo delsand technologies ,NewYour,NY,2003,pp.93{99,ACMPress. [46]DieterFensel, Ontologies:AsilverBulletforKnowledgeManagementand ElectronicCommerce ,SpringerVerlag,2003. [47]TrentJaegerandAtulPrakash,\Requirementsofrole-b asedaccesscontrolfor collaborativesystems,"in RBAC'95:ProceedingsoftherstACMWorkshop onRole-basedaccesscontrol .1996,p.16,ACMPress. [48]MargaretLeviandLauraStoker,\Politicaltrustandtr ustworthiness," Annual ReviewofPoliticalSciences ,vol.3,pp.475{507,2000.

PAGE 104

94 [49]RoderickM.Kramer,\Trustanddistrustinorganizatio ns:Emerging perspectives,enduringquestions," AnnualReviewofPsychology ,vol.50, pp.569{598,1999. [50]AlfarezAbdul-RahmanandStephenHailes,\Supporting trustinvirtual communities,"in HICSS-33:HawaiiInternationalConferenceonSystem Sciences ,Washington,DC,2000,IEEE. [51]MortonDeutsch,\Cooperationandtrust:Sometheoriti calnotes,"in Nebraska SymposiumonMotivation ,M.R.Jones,Ed.1962,NebraskaUniversityPress. [52]DiegoGambetta,Ed., Trust ,Oxford:BasilBlackwell,1990. [53]GirishSuryanarayanaandRichardN.Taylor,\Asurveyo ftrustmanagement andresourcediscoverytechnologiesinpeer-to-peerappli cations,"Tech.Rep. UCI-ISR-04-6,InstituteforSoftwareResearch,Universit yofCalifornia,Irvine, 2004. [54]PeterA.Dinda,\Addressingthetrustasymmetryproble mingridcomputing withencryptedcomputation,"in LCR'04:Proceedingsofthe7thWorkshop onWorkshoponlanguages,compilers,andrun-timesupportf orscalable systems ,NewYork,NY,USA,2004,pp.1{7,ACMPress. [55]D.Gritzalis,Ed., SecureElectronicVoting ,KluwerAcademicPublishers,2003. [56]S.Marsh, FormalisingTrustasaComputationalConcept ,Ph.D.dissertation, UniversityofStirling,1994. [57]V.ShmatikovandC.Talcott,\Reputation-basedtrustm anagement,"in ProceedingsofWorkshoponIssuesintheTheoryofSecurity( WITS) ,2003. [58]\Ebayfeedbackscheme,"http://pages.ebay.com/help /feedback/evaluatingfeedback.html(July10,2005).

PAGE 105

BIOGRAPHICALSKETCH VijayManianwasborninChennai,India,in1977,thesonofPa dmaand S.V.S.Manian.Hehastwoeldersisters,ChithraandVidya.A ftercompleting hisprimaryschoolinginChennai,heattendedIdaScudderSc hool,Vellore,India, wherehecompletedhisX.HecompletedhighschoolfromPadma SeshadriBala BhavanJuniorCollege,Chennai,in1995.HereceivedaBache lorofEngineering degreeincomputerscienceandengineeringfromtheUnivers ityofMadrasin 1999.Hethendecidedtopursuehismaster'sdegreeincomput ersciencefrom theUniversityofFlorida'sComputerandInformationScien cesandEngineering Departmentin1999.AfterobtainingaMasterofSciencedegr eein2002,he continuedontothePh.D.program.Helooksforwardtoahopef ullysuccessful careerinthesoftwareindustry. 95