MODELLMG UNIX SYSTEM SECURITY WITH A ROLE GRAPH

by

Lingling Hua

Department of Cornputer Science

Submitted in partial fuifilment of the requirements for the degree of

Master of Science

Faculty of Graduate Studies The University of Western Ontario

London, Ontario January, 1998

O Lingling Hua, 1998

National tibmy Bibliothèque nationale du Canada

Acquisitions and Acquisitions et Bibliographie Services seMces bibliographiques

395 wenington Street 395, Ne welüngtosi -ON K I A W Ottawa ON K1A ON4 canada canada

The author has granted a non- exclusive licence allowing the National Library of C d to reproduce, loan, distnbiie or sell copies of this thesis in microform, paper or electronic formats.

The author retains ownership of the copyright in this thesis. Neither the thesis nor sub~bntial extracts fkom it may be printed or otherwise reproduced without the author's permission.

L'auteur a accordé une licence non exclusive permettant à la Bibliothèque nationale du Canada de reproduire, prêter, distriiuer ou vendre des copies de cette thèse sous la forme de microfiche/fïlm, de reproduction sur papier ou sur format électronique.

L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation.

ABSTRACT It is important that a user's home directory be properly protected in a W I X

system. It is recognized that if the system administrators monitor and control the

security of users' home directories on a regular basis from a single point. this can

effectively improve the security of users' home directories on the system. However.

this security measure is dificuit to carry out.

As a solution. this work provides a Role Graph Monitor (RGM). which

combines UNIX and role-based access control by using role graphs to mode1 the

access permissions of users' home directories in a üNIX system. The requirements.

design and the implementation for the RGM are presented. Our experimental results

show that the role graph is a powerful tool and provides the UNIX system

administrators with the ability to monitor the security of the usersg home directories

easily and effectively.

ACKNOWLEDGMENTS 1 would like to thank my advisor, Dr. S. L. Osbom for providing invaluable

advice and motivation needed to complete this work. Thanks also go to Dr. Hanan

Lutfiyya for her helpful suggestions whenever 1 approached her with questions.

1 would also like to thank Chi Zhang for her work on the Role Graph Generator.

The Role Graph Generator II in this thesis is based on her work.

Finally. 1 would like to thank my farnily and especially my husband Junjie

Zhang, for his patience. understanding and encouragement through my years in

western.

TABLE OF CONTENTS

CERTIFICATE OF EXAMINATION

ABSTRACT

ACKNOWLEDGMENTS

TABLE OF CONTENTS

LIST OF FINGURES

11

III

IV

v

CHAPTER 1 INTRODUCTION 1

1.1 STATEMENT OF THE PROBLEM ......................................... . ............................... 1

3 1.2 ROLE-BASED ACCESS CONTROL AND ROLE GRAPH MODEL .................................., 3 1.3 THESIS SCOPE ....................................... .. ................................... ............................. -

1.4 OUTLINE OF THESIS ............................................................................................... 3

C W T E R 2 UNIX FILE SYSTEM SECURITY 4

2.1 UNIX SYSTEM SECURITY ....................... .... .... . .... . .. . ... . ... ... . . . . . . . . . . . . . . 4

2.2 UNIX FILE ACCESS PERMISSION ......................................................................... 5

2.2.1 Access Permissions for Files.. . . . .. . .. . . . . . . .. . . . .. . . .. .. . .. .. . .. . . . . . . .. . . . .. .... . . .. . . . . . . . . . . . . . .. .6 2.2.2 Access Permissions for Diredories ..... .... ..... ... . .... ... ...... . ..... ........ .. . .... .... . ...... . 7

2.2.3 The Types of Access.. . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . 8

2.3 MAINTAINING AND CHANGING FILE SECURITY .................................................... 9

2.4 THE SECURITY OF HOME DIRECTORIES ............................................................... 10

5.2.2.1 Monitor the Security of Home Directones ............................................. 43

....................................................... 5 2.2.2 Assign Values to Global Variabies -43

....................................................................................... 5 . 2.2.3 Generate Roles 44

................................................................................ 5-23 Role Graph Genrrafion 50

........................................................................... 5.2.3 . 1 Generate the Role File 5 0

....................................................................... 5.2.3 -2 Generate the Role Graph 5 2 -9 ................................................................................. 5.3 IMPLEMENTATION OF RGM 33

- ? 5.4 SUM ..................................................................................................................... 33

CHAPTER 6 EXPERIMENTAL RESULTS 54

CHAPTER 7 CONCLUSIONS 72

APPENDIX A THE USAGE OF THE RGM 75

REFERENCES

VITA

vii

LIST OF FINGURES

Figure 2.1 The Modification Graph of the X Bit ......................................................... 8

Figure 3.1 Three Kinds of .4 uthorization ..................................................................... 15

.............................................................................. Figure 3.2 Example of Role Graph 18

Figure 5.1 The Class Relationship Structure .......................................................... 17

............................. ............. Figure 5.2 Class Member Definition .... .... ........................ 29

........................................................................... Figure 5.3 Class Pnvilege Definition 31 . .

Figure 5.4 Class Roleid Definition ............................................................................... 32 .

Figure 5.5 Class RoIe Defirution ................................................................................ 34

Figure 5.6 Class Roleset Definition ........................................................................... 37

Figure 5.7 Template Class Item Definition ................................................................ 40

..................................... Figure 5.8 The interface to Prompt the User for Sub-systems 42

Figure 5.9 The Algorithm of Member Function link-role of Class Roleset ................ 44

Figure 5.10 The Algorithm of Mernber Function relationship of Class Roleset ......... 45

Figure 5.1 1 The Algorithm of Member Function related-object of Class Role .......... 46

Figure 5.1 2 The Algorithm of Member Function set-role-level of Class Roleset ...... 49

Figure 5.13 The Format of a Role File ......................................................................... 51

Figure 5.14 The Information of a Role ........................................................................ 52

. . Figure 6.1 The Role Graph of Example 1 .................................................................... 33

Figure 6.2 The MaxRole of Example I .................................................................... 56

Figure 6.3 The MinRole of Example 1 .................................................................. 56

Figure 6.4 The Role Graph of Example 2 ................................................................. 57

Figure 6.5 The MaxRole of Example 2 ........................................................................ 58

........................................................................ Figure 6.6 The MinRole of Example 2 58

Figure 6.7 The Role Graph of Exarnple 3 ................................................................ 59

....................................................................... Figure 6.8 The MaxRole of Example 3 -60

Figure 6.9 The MinRole of Example 3 ..................... .... ........................................ 60

Figure 6.10 Role 3 of Example 3 .................... ..... ............................................... 6 1

Figure 6.1 1 The Role Graph of Example 4 .................................................................. 62

Figure 6.12 The MaxRole of Example 4 ...................................................................... 63

Figure 6.13 The MinRole of Exarnple 4 ................................................................... 64

Figure 6.14 Role 2 of Example 4 ............................................................................... 64

Figure 6.1 5 The Role Graph of Example 5 ................................................................. -65

Figure 6.16 The MaxRole of Example 5 ..................................................................... 66

Figure 6.1 7 The MinRole of Example 5 ...................................................................... 67

Figure 6.18 Role 3 of Example 5 ................................................................................. 67

Figure 6.1 9 The Role Graph of Exarnple 6 .................................................................. 68

Figure 6.20 The MaxRole of Example 6 ...................................................................... 69

Figure 6.2 1 The MinRole of Example 6 ...................................................................... 70

Figure 6.22 Role 4 of Exarnple 6 ................................................................................. 70

Chapter 1

Introduction

1.1 Statement of the Problem

It is important that a user's home directory is properly protected in a UNIX

system. One example is that users can add files to your home directory or delete files

fiom it if they have w permission for your home directory [I l . Of course. they can

add their own files with Trojan horses to it, in which case your account couId be

broken into [2]. The most terrible thing is that Duffs virus attack made use of

people's wite home directories and write sub-directones with great success [j].

Another example is that if persons have x permission to your home directory. they

may access its files if they have permission to access individuai files [ I l . They can

run prograrns or open files or write files in it. For instance, if they have write access

to your stamip files, they could add commands to them. Therefore. your account

could be taken over easily [2] .

There are two ways to improve the security of users' home directories. One is

to educate users to protect their home directones properly [2]. The other is to have the

system administrators monitor the security of users' home directories on a regular

bais and control the security of them from a single point. However. these securit):

measures are difficult to be carried out. When implementing the second measure. the

system administrators need to have a clear picture of who can access whose home

directory and in what modes (r, w, x) they can access it. This is not easy to be

achieved for three reasons. Firstly, there are usually a large number of home

directories in the system. Secondly, for every home directory there are three sets of

access permissions specified independentiy for the owner, for those in the orner's

group, and for al1 others [l]. Xrd ly . each set of permissions contains three identical

permission bits (r, w, x) [2] (It should be noted that the x bit c m be replaced with set-

group-id bit, set-user-id and sri& bit). As the UNIX system becomes networked and

has more and more users, this task becornes even more difficdt. Thus. it is important

that we device methods that will enable the üNIX system administrators to monitor

the security of the users' home directones easily and effectively. A role graph is one

powerful tool to do that [4] [5].

1.2 Role-based Access Control and Role Graph Model

Role-based access control (RBAC) provides a way of managing authorizations

in complex systems. By definition, a role consists of a role name and a collection of

priviieges [5]. Roles could be predefined and users be assigned to roles according to

their job fûnctions in the organization [6] . A pnvilege consists of an object and a set

of access modes for that object [7]. Relationships can exist arnong roles. such as role

hierarchy and mutual exclusivity [6]. Nyanchama and Osbom's role graph mode1

uses a graph to visualize role hierarchy relationships [4] 151. A role graph has the

following six properties: 1. There is a single MaxRole that contains al1 the privileges

in the system. 2. There is a single MinRole that contains the minimum set of

pnvileges that every user must have in the system. 3. The role graph is acyclic. That

means roles offer differentiated access to the objects in the system. 4. There is a path

fiom MinRole to every other role in the system. 5 . There is a path from every role to

MaxRole. 6. For any two roles A and B, if role B is a junior role of role A. then there

must be a path from role E3 to role A.

1.3 Thesis Scope

The aim of this thesis is to use role graphs to monitor the security of usen'

home directories in the UNIX system. Once the role graphs are completed. it is

expected that monitoring the security of users' home directones in the UNIX system

will become an easier task.

1.4 Outline of Thesis This thesis will combine UNIX and role-based access control by using role

graphs to model the access permissions of users' home directories in a W I X systern.

In order to model the security of home directories. a piece of software called the Role

Graph Monitor (RGM) has been written in C++. UNUC sheil scripts and [ci. This

software monitors the security of home directories and outputs a role graph to

visualize the security status.

The thesis is organized as follows. It begins with a bnef overview of the

literature. Chapter 3 describes UNIX file system security. An introduction to role-

based access control and role graph mode1 is given in chapter 3. The requirernents for

the Role Graph Monitor (RGM) are analyzed in chapter 1. In chapter 5. the design

and the irnplementation of RGM are discussed. Chapter 6 demonstrates expenmental

results. Finally. chapter 7 summarizes the conclusions and points out possible fùture

research directions.

Chapter 2

UNIX File System Security

2.1 UNIX System Security

The W I X operating system, developed in the 1970s at Bell Laboratories. was

created to be used in 'fnendly' environments in which programmers typically

collaborated with each other on projects. Hence. there was no special need for

security. However, in the early 1980s. as businesses. govemments. universities and

industrial secton began to install UNIX systems. It was no longer being used only in

environments where open collaboration was the primary goal. System secunty

demands have been rising rapidly since then.

In generai, the UNIX security matters can be broken d o m into four general

areas of concern: 1. preventing unauthorized access. 2. preventing compromise. 3.

preventing denial of service, and 4. preserving the integnty of the systern. Over the

years, security mechanisms have been gradually added to the UNIX system to take

care of these security issues, such as the login and password mechanisms (to achieve

authorized access) and the file permission mechanism (îo prevent compromise) [1 O].

2.2 UNIX File Access Permission

In UNIX, each file or directory has three sets of permissions associated with it:

one set for the owner of the file, one set for the group with which the file is associated.

and one set for ail other users ('world'). They are represented symbolically as u. g.

and O respectively. Each set of permissions contains three identical permission bits:

they are: r w x.

r represents read access permission. w represents ivrite permission and x

represents execute permission.

In addition, there is a fourth set of three bits that indicate speciai features

associated with the file. They are: set-user-id, set-group-ia: sticky.

In a listing, set-user-id is indicated by an s or S replacing the x in the orner's

permissions. Its setting or clearance is done by issuing cornand -'chmod u+s" or

"chmod u-s". The Set-group-id bit is specified by an s or S in the x position of the

group permissions. Its setting or clearance is done by using g'chmod g+s" or "chrnod

g-s". The sticky bit is indicated by a t or T replacing the x in the others permissions.

But the letter t only works with u. that is, it is meaningful only for the owner of the

file. The setting and clearance of sticky are carried out by "chmod u+t" and "chmod

u-t". For these three access permissions, if a small letter is specified. it represents that

both the x permission and the permission this small letter indicates are ~ m e d on.

Otherwise. only the permission the (capital) letter specifies is turned on. The setting

processes can be represented by graphs as shown in figure 2.1.

These access permission bits have different rneaning when applied to files and

directories. Their indications are explained in the following two subsections.

It should be noted that some UNIX systems have replaced this file protection

mode to access control lists (ACLs) [ I l ] . Every file h,as an ACL. which allows the

owner to determine which other users rnay have access to this file and in what access

modes. When a file is accessed, the ACL is processed in order, appiying each list

entry to the user. When a match is found, those permissions are applied.

w a. The Modification graph of x bit

in the owner's permission set

b. The Modification graph of x

in the group's permission set

u c. The Modification graph of x bit

in the other's permission set

bit

Figure 2.1 The Modification Graph of the x bit.

2.2.1 Access Permissions for Files [2]

read If set, the file may be read.

write If set, the file may be written (modified).

execute If set, the program contained in the file may be executed (run).

Executing compiled programs requires only execute permission on the

file, while executing shell scripts requires both read and execute

permission since the shell must be able to read cornmands from the

file.

set-user-id Set-user-id statu means that when a program is executed. it

executes with the permissions of the user who owns the program. in

addition to the permissions of the user executing it. The effective user

id of the process becomes the id of the owner of the executable file.

The real user id of the process remains that of the user who initiated the

process. This bit is meaningless on non-executable files.

set-gr0 up-id It behaves in exactly the same way as the set-user-id bit.

except that the program operates with the permissions of the group

associated with the file. When a process is executed with set-group-id bit

turned on, the effective group id of the process becomes the group id of

the owner of the executable file and the program thus executes with

permissions of that group. The real group id of the process remains that of

the user who initiated the process. This bit is meaningless on non-

executable files.

sticky If set on an executable binary file, the 'sticky' bit tells the operating

system to maintain the image of the executing process in the swapping

area, even when the execution is terminated.

2.2.2 Access Permissions for Di rectories

read Read permission allows a user to see the contents (file names) of

the directory. but is insufficient for accessing the files whose names

appear in it [ I l . For instance, you can not read the contents of a file in a

directory if you only have r access to the directory.

write Write permission to a directory implies the ability to create.

delete, and renarne files in this directory. The w permission for a

directory is required in order to add files to it or delete files from it.

However. w permission for a directory is not required in order to modifi a

file listed in the directory or delete its contents (11.

execute In the case of a directory, execute permission implies access the files

contained therein. It allows you to operate on the names in that directory

if you know them, but does not let you find out what they are if you don't.

Nomally r is granted whenever x is; you c m get some strange effects if a

directory has x but not r. For instance, if a directory has x turned on but

not r, you can't list its contents-but if you already know its contents. you

might be able to read its files if you had that permission[l].

set-user-id This bit is meaningless on directories[l].

set-group-id On some systems this bit has a special rneaning when set on

directones. For example, in SunOS 4.x, the group id of a file is set to

the group id of the directory in which it is created if the set-group-id is set

on the directory. Otherwise, the group id of a file is set to the

primary group id that the owner belongs to [2].

If a directory has its sticky bit set. users may not delete or rename

files in this directory that are owned by other users [2 ] . The sticky bit is

usually set on world-writable directories.

2.2.3 The Types of Access

The file security methodology used by UNIX is based on the concept that there

are three types of access: world, group, and owner.

World-level security. as its name implies, refers to the entire user community on

the UNIX platform [8]. It points out what these users can do to the file.

Group-level security refers to users who are given a specific group identifier 181.

Groups allow you to place usen in convenient categories. With newer versions of

UNIX, a user can belong to several groups at one tirne; thus usen whose duties cross

group boundaries cm be handled as well. Groups are set up via the etclgroup file (if

MS is being used to adrninister this configuration file, groups are set up via the NIS

database group). In the file are assigned of a group name. group number (O to

32,767) and group member list. Users c m belong to eight or more groups at one tirne.

The default group (base-levei group) for a user is assigned via entry in the

letclpasswd file (if NIS is being employed. there is a NIS database called passwd to

replace this file). Under old versions of UNIX. a user can only belong to one group al

one time. The "newgrp" command is used to let the user change to other group.

Owner-level security is what the owner of the file can do to it.

The combination of world, group, and owner security profiles is stored in the

file's inode and is referred to as the file's mode.

UNIX always checks permissions for the smallest category that applies. For

instance, a user in the owner's group (other than the owner) is always given the group

permissions even if the permissions for "others" are broader[l 1.

2.3 Maintaining and Changing File Security

The owner can change the security of his or her own files. The owner-based

protections are more of a protection from brain lapses than frorn any security hazard.

The root or super-user account maintains file security for the entire systern. The

system administrators should check for security problems in the file system on a

regular basis. They should check files that cm inadvertently grant users too many

permissions, and files thac can inadvertently gant access to intruders. such as set-

group-id and set-user-id files, world writeable files and directories. and unowned

files. These can be carried out by using afind command with different options. It is

also important to be able to detect unauthorized modifications to the file system, and

to be able to recover fiom these changes [2].

There are four commands designed to maintain and change file security:

m: this utility changes the group that is associated with a file. Only the

owner of a file or the super-user can change the group association of a file. You must

belong to the specified group as well as be the owner of the file (unless you are the

super-user).

chmod: this utility changes the ways in which a file can be accessed by the

owner of the file. the group to which the file belongs, and/or ail other users. Only the

owner of a file or the super-user can change the access mode. or permissions. of a file

or directory. Only the super-user may set the sticky bit on a non-directory file. If you

are not the super-user, chrnod will mask the sticky-bit but will not retum an error.

You cm specify the new access mode absolutely or symbolically. but sel-group-id

m u t be cleared or set by symbolic mode using g+s or g-S. In order to tum on a file's

set-group-id bit, your own group ID must correspond to the file's and group execution

must be set [12].

chown: this utility changes the owner of a file. Some systems are

configured so that only the super-user c m change the ownership of a file.

umask: this command specifies a mask that the system uses to set up access

permissions when you create a file. It generally appears in the .profile or .login file

[12]. The urnask value should be set to something appropriate to the secunty

requirements. On most systems, the default umask value is 022. which indicates that

write permission for the group (20) and others (2) should be turned off whenever a file

is created [2] .

2.4 The Security of Home Directories

The home directory is the working directory when you first log in on a üNIX

system. The location of a home directory is specified in the /etc/passwd file or in the

NIS database passwd. The pathname of this directory is stored in the HOME shell

variable [12].

Al1 the user's files are under the user's home directory, including the startup

files and some directories. The user can grant other users access to bis/ her files. For

exarnple, the user gives other users in the owner group of one of hislher files read.

write and execute permission to this file. Suppose that this file is under the user's

home directory directly. As discussed in section 2.3, we know that the users in the

owner group of the file c m actually read, write or execute i t only if they are also

granted execute permission to the user's home directory. If the file is Iocated under

one sub-directory of the home directory. these users need not only execute permission

to this sub-directory, but also execute permission to the home directory in order to

read. write or execute this file.

The home directory is the ultimate outer defense against an attack to an account.

As pointed out previously, the account could be easily broken into or taken over when

the security of the home directory is poor. On the other hand. if the home directory

was protected properly, even if the files it contains are granting access to intmders.

they wodd be protected effectively. One exarnple would be that. without x

permission to your home directory, even if they are ailowed to wite to your startup

files. the attackers c m not access them. This could be paraileled with the situation the

closet containing your valuables is not locked. I f you leave the door of your home

open, there is much chance that the valuables would be taken away by a thief. But if

the door of your home is locked, the chance the thief takes the valuables away would

be much less than that of the first situation. This is why we are concentrating on

home directory security instead of file security in this thesis.

Chapter 3

Role-based Access Control (RBAC)

and Role Graph Model

3.1 Introduction

System architects and users recognized the need for information security with

the advent of the first multi-user cornputer systems 1131. Different kinds of access

control models have been built over the yean to ensure that only authorized users are

given access to certain data or resources. Role-based access control that was

developed in the 1980s is one of them.

RBAC provides a way of managing authorizations to perfonn tasks in cornplex

systems with many users and many resources [6]. With RBAC. security is managed

at a level which corresponds closely to the organization's structure. Roies are used to

group together permissions in ways that make sense in an application environment.

Individual users or groups of people can then be assigned to the roles as required [4]

and then can access certain resources.

RBAC has attracted much interest in the research community and vendor

community. Considerable research activity is being dedicated to RBAC. A number

of models have been suggested to solve RBAC configuration design and analysis.

such as the Nyanchama role graph model, the family of four conceptuai models and

the role profile model.

In this chapter we will introduce the basic concepts of role-based access control.

examine why it is attracting so much attention, and review one of RBAC

configuration design and analysis models - Role Graph Model.

3.2 RBAC Terms and Concepts

Before explaining what is role-based access control, we first define some

RBAC control terms and concepts.

~Object: A passive entity that contains or receives information [6]. It c m be

an operating system resource, a file, even a subject.

~Subject: An active entity, generally in the form of a person. process. domain

or device, that causes information to flow among objects or changes the system state

161

l Access: A specific type of interaction between a subject and an object that

results in the flow of information fkom one to the other. such as read. write. execute

on a program. use a printer. etc. [6] .

Access control: The process of limiting access to the resources of a system

only to authorized programs, processes. or other systems (in a network) [6].

l User: Any person who interacts directly with a computer system[6].

l Permission: Also called pnvilege. operation or right. A description of the

type of authorized interactions a subject cm have with an object [6].

A permission can be represented as a pair ( X m), where x refers to an object.

and m is a non-empty set of access modes for object x [4]. The exact nature of x and

m is a matter of the application environment and the associated security policy [4].

For example, in an operating system, x can be any identifier that uniquely identifies a

file. a directory, a device, and a port, m can be any operations such as read. write and

execute,

Relationships can exist among privileges, such as containment and mutual

exclusivity [4]. For example, the privilege that allows a user to update a set object

might imply that any such user should be able to read the individual object in the set:

this is a containment relationship. The privilege to set the pnce of a specific item is

conflicting with the privilege to purchase that item; this is a mutually exclusive

relationship.

Role: A job function within the organization that describes the authonty and

responsibility conferred on a user assigned to the role [6].

From a structural perspective. a role can be a named set of pnvileges. and can be

represented by a pair (marne. rpset), where marne is the name of the role. and rpset

represents the set of privileges of the role[4]. The names given to roles match job

titles [4]. Sometimes the terni roles is also used to refer to structure which includes

both users and permissions.

Relationships can exist arnong roles. such as a role hierarchy or rnutual

exclusivity. For instance. role warehouse and role customer are mutually exclusive

roles.

l Role hierarchy: A partial order relationship among roles (61.

Under RBAC. roles can have overlapping responsibilities and privileges. that is.

users belonging to different roles may need to perform comrnon operations. In this

situation, it would be inefficient and adrninistratively cumbersome to speci-

repeatedly these general operations for each role that is created. Role hierarchies can

be established to provide for the natural structure of an enterprise. A role hierarchy

defines roles that have unique attnbutes and that may contain other roles: that is. one

ro le may implicitly include the operations that are associated with another role [ 1 41.

Given two roles A and B. rote A is cailed role B's senior role and role B is

cailed role A's junior role, if role A's privileges include those of role B's. Role A

and role B are in an is-junior relationship [SI.

A role hierarchy is a reflexive, transitive, and antisyrnrnetric relation.

~Three kinds of authorizations: (See Figure 3.1 [4] )

User-Role authorization: Also called user assignrnent. It refers to the

assignment of users/groups to roles. It is a many-to-many relation.

Role-role authorization: It refers to a role hierarchy relationship among roles.

It is one way to assign privileges to roles (senior roles include pnvileges of junior

roles).

Role-privilege authorization: Also called permission assignment. It is another

way to assign privileges to roles. It is also a many-to-many relation.

Userd Groups

User-Group Us1

Roles

-Role Role-Role Rc

Privileges

0-

Privilege-Privilege

Membership Authorization Authorization Authorization Implication - -

Figure 3.1 Three Kinds of Authorization

Who is authorized to do what is determined by these three authorizations and

the relationship among privileges. Given a user-privilege pair. the decision of

whether the user is authorized to the privilege can be decided by checking these three

authorizations: user-role authorization, role-role authonzation, role-privilege

authorization and the reiationship among privileges sequentially.

Constraint: Constraints can be put on user-role authorization. role-privilege

authorization. role-role authorization, the user and role fùnctions for sessions. etc.

Constraints generally include cardinali~ and murual exclusivity [6].

3.3 What is Role-Based Access Control

In role-based access control, access decisions are based on the roles that

individual users have as part of an organization.

The process of defining roles should be based on a thorough analysis of how an

organization operates, and should include input from a wide spectrum of users in an

organization. Access rights are grouped by role. For example. within a hospital

system the role of doctor can include operations: performing diagnosis. prescribing

medication. and ordenng laboratory tests. [ 1 41

Users are granted into roles based on their cornpetencies and responsibilities in

the organization. The operations that a user is permitted to perform are based on the

user's role.

User membership in roles c m be revoked easily and new memberships

established as job assignments dictate [14]. Roles can be granted new permissions as

new applications and actions are incorporated, and permissions can be revoked from

roles as organizational functions change and evolve [15]. This simplifies the

administration and management of privileges; roles can be updated without updating

the privileges for every user on an individual b a i s [14].

RBAC directly supports three well- known security principles: leusi privilege.

Sepuration of duties, Data abstraction [6]. M A C allows for incorporation of

application-level security constraints and semantics. It also allows for

multidirectional information flow policies [I 61.

By role hierarchy, RBAC represents role-role relationship and provides the

naturai structure of an enterprise.

3.4 Nyanchama Role Graph Mode1 141 [5]

Before introducing the role graph, several notations used in the role graph

mode1 are presented.

Cornmon junior: A role is a common junior of two other roles if it shares

some privileges with both of these two senior roles.

Cornmon senior: A role is a comrnon senior of two other roles if it

encompasses al1 of the pnvileges of these two junior roles.

MinRole: The cornmon junior of al1 roles in the system. MinRole is always

defined in this model and the privilege set could be empty.

MaxRole: The comrnon senior of ail roies in the system. MaxRole is also

always defined in this rnodel and doesn't need to have any users authonzed to it.

Direct Privileges of role r: Those privileges that are not contained in the

priviiege set of any of r's irnmediate juniors.

Effective Privileges of role r: The union of its direct privileges and the

effective privileges of al1 its juniors.

3.4.1 Role Graphs

The main idea of the role graph model is to use a graph to visualize the role

hierarchy relationship. Both role hierarchy and conflict of interest are considered in

ihis model. An example role graph is shown in figure 3.2. In the role graph. the

nodes represent the roies in the systern, and the edges represent the is-junior

relationship. Role graphs have the following Role Graph Properties:

-There is a single MaxRole.

-There is a single MinRole.

-The role graph is acyclic which means roles offer differentiated access to the

objects in the system.

-There is a path from MinRole to every other role in the system.

-There is a path from every role to MaxRole.

-For any two roles A and B, if the pnvilege set of role B is a subset of that of

role A, then there must be a path fiom role B to role A.

Figure 3.2 Example of role graph.

3.4.2 Role Graph Maintenance Algorithms

The algorithms for role addition, privilege addition. role deletion. pnvilege

deletion, edge insertion, edge deletion and role partition have been developed. In [j].

the algorithms represent a beginning in the construction of a role management tool. In

[4], these algorithms are more mature, and privilege conflicts are considered.

There are two types of role addition algorithms. One provides information in

ternis of role-to-role relationships. It takes as input a role graph. a new role

represented by a role name, set of direct privileges, the roles that are to be its

immediate seniors and juniors. The other one just specifies the new role name and

effective privileges, and the algorithm determines the new role's junior and senior

roles by comparing privilege sets.

Role deletion algorithms offer the option of deleting the direct privileges of the

role being deleted from the graph altogether, or of reassigning al1 of the direct

privileges to the immediate seniors of the target node.

If any inconsistency is discovered in performing the operation, the user is told of

the problem, and the role graph is left unchanged.

The algorithms mentioned above are presented in appendix of [SI and [4].

3.5 Conclusion

Although RBAC has a long way to go before it reaches its full potential as a

commercially mature technology, the use of roles to control access is proven to be an

effective means for developing and enforcing enterprise-specific security policies. and

for streamlining the security management process [ 141.

Chapter 4

Requirements for RGM

(Role Graph Monitor)

4.1 Main Objective

So far. we have introduced the CTNIX file system security and have described

the main characteristics of the role graph model. Now, we can state the objective of

this thesis more clearly .

The objective of this thesis is to use role graphs to monitor the security of users'

home directories in the W I X system. The users' home directones refer to the home

directories of real-user accounts, not including those of othrr types of accounts. such

as administrative accounts. expired accounts, etc. Once the role graphs were

completed. it was expected that monitoring the securïty of users' home directories in

the UNIX system would become an easier task. The role graphs visualize the access

permissions of usen' home directories. Through these role graphs the system

administraton can analyze the users' home directory security. They can decide which

group is not trusted enough to have the privileges it is having and cam, out

corresponding actions.

It m u t be noted that the role graphs are only used to present a clearer picture of

the current security status of the home directones compared to what is currently

provided by the traditional UNIX file system. Therefore, the role graph management

algorithms (see Chapter 3) are not considered in the role graphs in this thesis.

4.2 Research Environment

The research environrnent of this thesis is the research network in the Computer

Science Department at the University of Western Ontario.

The Network Information Service (NIS) is employed to manage system

configuration files (such as Ietdpasswd. /etc/group, etc.) on the research network. By

carefully reviewing the NIS database passwd. we found several rules about the

configuration of the home directories in this system:

The home directories of expired accounts are set to be "Imp".

The home directories of those non-user accounts, such as administrative

accounts. vendor accounts and service accounts, are configured arbitrarily.

The home directories of real-user accounts are defined under six sub-

directones of directory "/csd". These six sub-directories are called /csd/faculty.

/csd/grad, /csd/undrgrad, Icsdproject, /csdslum, and Icsdpeople respectively. The

configuration of these home directories follows these d e s ;

i The home directories of faculties are placed under /csd/faculty.

Those of graduate students who write a thesis are set under /csd/grad.

Those of undergraduate students are put under Icsd~undrgrad.

i Those of graduate students who do project are settled under /csd/project.

The staffs' home directories are located under /csd/slum.

The home directories of visitors or sorne other type users are imposed

under lcsd/people.

As pointed out earlier. only the home directories of real-user accounts are to be

monitored in this thesis. Those six directories under which the real-user home

directories are located are considered as six sub-systems. The six sub-systems are

identi fied as faculry, graduate, undergruduale, project. staff and people, respec tively .

In the rest of this thesis, when we talk about a sub-system, we are refemng to one of

those six sub-directories.

In this thesis, a role graph could be drawn for the home directories either in one

of the six sub-systems or in any combination of those six sub-systems.

4.3 Privilege and User In this thesis, a privilege is defined as a home directory and a set of access

permissions to it, such as read, write, execute. etc.

A user as the unit assigned to roles would be a group in the NIS database group.

In other words, a group wouid be treated as the access unit to the home directories

instead of a single user. The reasons are the following:

The file security methodology used by UNIX system is based on the notion that

there are three types of access: world, group, and owner 181, which are represented

symbolically as O, g, u, respectively. World-level security. as its name implies.

refers to the entire user community on the LJNIX platform. Group-level security

refers to users who are given a specific group identifier. Owner-level security is

what the owner of the file can do to it.

Every file, including the users' home directory. belongs to a group.

The owner is tnisted with respect to his/her own files. so we do not wony about

the access permissions the file's owner has to this file. We care only about the

access permissions the owner group and al1 the others have to this file.

UNIX always checks permissions for the smallest category that applies. For

instance. a user in the owner's group (other than the owner) is always given the

group permissions even if the permissions for "others" are broader. So the world-

level security could be represented as severai group-level securities. These groups

are specified in the file /etc/group or the NIS database group, except the group to

which the file belongs.

A user can belong to as many groups as specified in the Ietdgroup file or the NIS

database group. It is important to know that every user belongs to at l e s t one

group (called base group) and the user's base group is defined in the /etc/passwd

fite r81 or the NIS database passwd.

By treating groups as the unit to roles, uses are assigned to roles and the user-

role authorization is simplified dramatically. If a user belongs to several groups at one

time, this user could be assigned to several roles through these groups.

It is assurned that a group must be assigned to one and only one role. We cal1

the role. to which the owner group of a home directory is assigned. the owner role of

this home directory. This owner role should have the access permissions specified by

the group-permission set of this home directory. Al1 the other roles should have the

access permissions specified by the world-permission set.

For a home directory, if there is an r specified in the read permission bit in the

group-permission set. then the owner role is given the read permission to this home

directory. If there is a w in the write permission bit. the owner role is assigned the

write permission to it. If there is an x indicated in the execute permission bit. the

owner role is granted the execute permission to it. The set-group-id bit is specified by

s or S in the x position of the group permissions. I f s is specified, it means that both

the execute permission and die set-group-id permission are tumed on. If S is

specified, only the set-group-id permission is nimed on. As stated in Chapter 2. this

bit is meaningless on non-executable files, but on some systems set-group-id has a

speciai meaning when set on directories. This is the case on the research network.

The group id of a file is set to the group id of the directory in which it is created if the

set-group-id is set on the directory [2] in this system. This bit has nothing to do with

the owner group's access permissions to the home directory. Therefore. when s is

appearing, execute access permission is given to the owner role. When S is appearing.

nothing will be done.

The situation of deaiing with the access permission bits in the others-permission

set is the same as that which deals with the access permission bits in the group

permission set, except that the access permissions are granted to al1 the other roles.

We know that the sticky bit is indicated by a t or T replacing the x in the others

permission set. It is usually set on world-writable directones. No sticky bit is set on

home directories on the research network. Consequently. we do not consider the

sticky privilege in this thesis.

4.4 Requirements for the RGM According to the main objective of this thesis. we identified three primary

requirements on which to base our Role Graph Monitor (RGM): sub-system choice.

role generation and role graph generation. The RGM should provide these three

h c t ions.

4.4.1 Sub-system Choice

The RGM will need the ability to represent those six sub-systems intemally. It

should provide an interface to let users choose which sub-systems are to be monitored.

The interface should be user-friendly and should be able to offer some means of

ensuring that the user enters a symbol that is defined on the interface. The interface

should allow flexible selection. in such a way, that the number of chosen sub-systems

could be fiom O to 6. The RGM also should submit an approach through which the

selection could be stored and retrieved.

4.4.2 Role Generation

To achieve the aim of this thesis. the RGM should at least provide services to

generate roles. The RGM should offer some means of finding al1 the groups on the

research network. Then it should be able to assign those groups into roles according

to the access permissions they have to the home directories in the sub-systems. The

groups assigned to the same role should have identical privileges. The RGM should

offer methods through which role-role relations could be identified. There are four

types of role-role relations: ancestral, descendent, direct-junior and direct-senior. If a

role has one of these relations with another role, it is called a related role of that role.

The RGM m u t provide a method to calculate the vertical levels where the roles are to

be placed in the role graph according to the relationship among these roles.

A suitable

structure should

data structure is

not ody be able

needed to represent the concept role. This data

to uniquely identify each role, but also be able to

reflect a role's privileges. users, related roles. vertical level. etc. The way in which

this data structure embodies that information should satisQ extensibility and

flexibility. The reasons are as follows:

New roles can be generated when a new job, new applications or new systems

appear(s). Existing roles can be deleted when a project or an assignment is complete.

New privileges can be granted to roles and present privileges can be revoked

fiom roles.

Users cm be reassigned to different roles and new users can be assigned to

existing roles.

As the privileges are granted to or revoked from a role, the originally related

roles may become unrelated. New related roles of a role may arise as new roles are

formed. The related roles of a role could disappear when existing roles are deieted.

The roles should be organized so that the task that identifies the relationships

among them can be finished easily and efficiently. Because of the frequent

appearance of new roles and the disappearance of existing roles. it also requires that

the way, in which the roles are organized, should be flexible and extensible.

The RGM should also provide some means to identiQ or create the MaxRole

and the MinRole for these generated roles.

4.4.3 Role Graph Generatioa

The ultimate task of this thesis is to use role graphs to visualize the access

permissions of user's home directories. Thus, the RGM should offer the fimctionality

to generate a role graph. The role graph should be based on the roles generated during

role generation. For each role, the role graph should specifi the users (groups here)

assigned to the role, the privileges the role has, the senior roles and the junior roles of

the role. The placements of these roles in the role graph are decided by their vertical

levels. The generated role graph should satise those six Role Graph Properties (see

Chapter 3). As stated in section 4.1. role graph management need not be considered

in the role graph.

4.5 Summary In this chapter we have descnbed the main objective of this thesis and the

research environment used to support the work reported. We have also explained the

meanings of concept privilege and concept user in this thesis. Furthemore. we

identified and discussed the basic requirements that the RGM must fdfîll. These

requirements were sub-system choice, role generation and role graph generation. In

the next chapter, we will provide the design and implementation of the RGM that

achieves those requirements.

Chapter 5

Design and Implementation of RGM

In Chapter 4 we identified the requirements for the Role Graph Monitor. In the

present Chapter we present the design and the implementation of the RGM. based on

those requirements. This chapter is organized as follows. Section 1 describes the

design of the main data structures in RGM. Section 2 describes the steps designed to

achieve the requirements. The implementation of RGM is introduced in section 3.

5.1 Main Data Structures in RGM

Roleset $1

Senior role Junior role

Figure 5.1 The CIass Relationship Structure

Member ( b D Privilege

Direct-senior role Direct-j unior ro le

Based on the requirement analysis of RGM in chapter 4. we have identified the

main data structures (classes). The OMT (Object Modeling Technique) diagram that

represents the relationships between them is shown in Figure 5.1. In this OMT

diagram, O represents aggregation [ 191.

Class Role is the data structure used to modei the concept role. Class Member

represents concept user. A role could have more than one user assigned to it and a

user could be assigned to more than one role. This is modeled as many-to-many

association between class Role and class Member. The Priviiege class is designed to

represent the access permissions that a role has. A Privilege objet stores a role's one

type of access permissions (read, write or execute). The reason we do this instead of

letting a Pnvilege object to represent one access permission is discussed below. at the

part where we describe class Privilege. A role has three types of access mode and a

Privilege object could be more than one role's one type of access permission. This

relationship is represented as many-to-many association between class Role and class

Privilege. We already know that a role could be several roles' senior role or junior

role and at the same time it could have many junior roles and many senior roles. This

is the many-to-many relationship in class Role. The class Roleset is used to represent

the data structure that organizes the roles. It is in aggregation relationship with class

Role.

How to represent the many-to-many association between class Role and class

Member and the association between class Role and class Privilege? Generally

speaking, many-to-many association is modeled as an association class. But in the

RGM, we usuaily only care about the impact of these associations to class Role. and

we don? care about the impact of these associations to other classes (class Member

and class Privilege). Consequently, we model these associations as attributes of class

Role. For users, we know that the users assigned to a role could be removed from this

role due to completion of the job and new users could be added to a role due to new

job assignments. Consequently, the data structure used to hold users assigned to a

role should have the characteristic of easy extension, easy search and easy deletion.

List is the perfect candidate. To fulfill these objectives, we introduce another class

called MemberItem in which there is a class Mernber object and a pointer to another

MemberItem object. For privileges, a role has three types of access mode. each one

associated with one attribute. Thus gives three attributes (three Privilege objects) to

mode1 the read, write and execute access permissions the role has to the home

directories in the system.

Another question is how to represent the role-role relationship in class Role.

For every role, we need to be able to quickly search its related-roles (junior roles.

senior roles. direct junior roles and direct senior roles) and delete or add its association

with other roles. Therefore, a role's one type of related roles should be linked

together. In order to Save space, we use a corresponding role id to uniquely identifi a

role. The corresponding class structure is called Roleid. In the class Role structure.

there are four role-id lists. The class that has a pointer to link role ids is called

Roleidtem. To achieve flexibility and extensibility, we link roles together in class

Roleset. The class to link roles is called RoleItem.

Following is the description of the classes we have in RGM.

The Member Class

1. Definition: A class Member object represents one user assigned to a role in this

study. In this class stmcture, there is only one data rnember to represent a user's

narne. The definition of this class is s h o w in Figure 5.2.

Member membername: * char Mem er (name: c ar) -Member ( ) set-membemame (narne: * char) get-rnembernarne ( ): * char r - l

Figure 5.2 Class Member Definition

2. Public Member Function Semantics

Member: It is the constnictor of the class Member. It initializes a user with the narne

given by the parameter. The default value of this parameter is empty.

-Member: It is the destructor of the class Member.

set - membername: This member fùnction sets the name of this user to the value

specified by the parameter.

getmembername: This member function retunis the name of this user.

The Privilege Class

1. Definition: The Pnvilege class is designed to represent the access permissions that a

role has. A Privilege object stores the permissions of only one type of access mode

(read, write or execute). In cornparison with letting a Privilege object to represent one

access permission, this method is more effective and easier to implement. A role's

privilege set is used to identify its relationship with other roles. We need operations

to determine the relationship of a role's privilege set with those of other roles.

Funhermore, operations are needed to combine roles' privileges and to get a role's

direct privileges. By treating al1 of a role's one type access permissions as a Pnvilege

object, these operations could be defined as member functions of class Pnvilege.

A Pnvilege object consists of 2 private data members and a number of public

member functions. One of its data member stores the permissions. It is designed to

be an integer array. The number of elements in this array is detemined by the number

of home directories in the chosen sub-systems. Every home directory is given a

sequence number according to the sequence in which it is visited. Every element of

this array corresponds to a related home directory according to its index. Its value

reflects whether there is access permission (read, write or execute) to this home

directory. Here I means "has" and O means "has not". The other data member is used

to reserve the number of home directones to which access permissions are granted.

The definition of class Pnvilege is given in Figure 5.3.

2. Public Member Function Semantics

Priviiege: This is the constnictor that initializes an object. Both of its data members

are set to O.

-Privilege: It is the destructor of the class Privilege.

can: an integer array cannum: integer

Pnvilege ( ) -Privilege ( )

operatoF @: & Privilege) operator+= (p: & Privilege) operator-= (p: & Privilege) operator&= (p: & Pnvilege) addqrivilege (sequence: integer) deleteqrivilege (sequence: integer) checkqrivilege (sequence: integer): integer juniorqrivilege @: * Privilege): integer get-cannum ( ): integer set-cannum ( n: integer)

Figure 5.3 Class Privilege Definition

operator-: This function assigns the values of the data members of the parameter

Pnvilege object to those of this Privilege object.

operator+=: This function adds al1 the access permissions the parameter Privilege

object has to this Pnvilege object. This function could be used to generate the

effective privileges of MaxRole.

operator-=: This function removes al1 the access permissions the parameter Privilege

object has from this Privilege object. This function could be used to generate the

direct pnvileges of a role.

operator&=: This function removes the access permissions this Privilege object has

and the parameter Privilege object has not frorn this Privilege object. This

function could be used to generate the privileges of MinRole.

addgrivilege: The function adds access permission to the home directory specified

by the parameter.

deleteqrivilege: The member funftion deletes the access permission to the home

directory specified by the parameter.

checkgrivüege: This function checks if this Privilege object has access permission

to the home directory specified by the parameter. The return value 1 means

"has" and O means "has not" .

juniorqriviiege: This fimction tests if the parameter Privilege object is junior to this

Privilege object. In essence. it tests whether the permission set of the parameter

object is the subset of this Privilege object. The r e m value 1 means "yes". O

means "no".

get-cannum: It retums the number of home directories to which access permissions

are granted.

set-cannum: It sets the nurnber of home directories to which access permissions are

granted to the value specified by the parameter.

The Roleid Class

1. Definition: This class is designed to denote the id of a role's related role. The

related roles of a role refer to the descendant. ancestral. direct-junior and direct-senior

roles of this role. This class's definition is given in Figure 5.4.

1 Roleid 1 roleid: integer

Roleid (id: integer) -Roleid ( ) set-roleid (id: integer) get-roleid ( ): integer

I Figure 5.4 Class Roleid Definition

2. Public Member Function Semantics

Roleid: This is the constructor. It initializes a Roleid object with role id given by the

parameter. The default value of this parameter is O.

-Roieid: This is the destructor of class Roleid.

set-roleid: Given an integer, this function assigns it to the role id of this object.

get - roleid: This fbnction returns the value of the role id of this Roleid object.

The Role Class

1. Definition: An object of class Role represents a role in this thesis. A Role object

includes several data members. One of them is an integer to reflect the id of this role.

One is a user list. Three Privilege objects store read. write and execute access

permissions to the home directones in the chosen sub-systems this role h a .

respectively. Other data members in a Role object include the vertical level of this

role in the role graph and four related role id lists. etc. The related role id lists refer to

the descendant, ancestral, direct-junior and direct-senior role id lists. The definition of

the class Role is demonstrated in Figure 5.5.

2. Public Member Function Semantics

Role: This is the constructor. It initializes a role with id equd to the global variable

roleid and vertical level O. Its user list, pnvilege sets and related role id lists are

set empty.

-RoIe: This is the destructor of class Role.

set-id: This member function sets the id of this role to the parameter.

get-id: This member fùnction r e m s the id of this role.

addqrivilege: This function is given two parameters. One of them is the sequence

number of a home directory. The other is the access mode (1 means read. 3

means wrîte, 3 means execute). Together, they represent an access permission

to a home directory. This member function adds the access permission to this

role.

deletegrivilege: This function removes the access permission specified by the

parameters fiom this role.

checkqrivilege: It checks if this role has the access permission specified by the

parameters. The retum value 1 means "has" and O means "has not".

Role id: tnteger mem berlist: * Memberttem readi ist: PriviIege writelist: Privilege executel ist: Privi lege directsenior: * Roleidltem directjunior: * RoleidItem ancestor: * Roleidrtem descendant: * RoIeidItem level: integer

Role ( ) -Role ( ) set-id (id: integer) get-id ( ): integer addgrivilege (sequence: integer, accessmode: integer) deletegrivilege (sequence: integer, accessmode: integer) checkgrivilege (sequence: integer, accessmode: integer): integer getprivilege-nurn (accessmode: integer): integer get-allqrivilege-num ( ): integer get-readlist ( ): * Privilege getwritelist ( ): * Privilege get-executelist ( ): * Privilege get-mernberlist ( ): * Memberltem add-member (m: * Member) delete-member (m: * char) has-equalqrivilege (accessmode: integer. r: * Role): integer relatedobject (r: * Role): integer operator= (r: & Role) directjunior (r: & Role): integer directIsenior (r: &Role): integer set-level (level: integer) get_level( ): integer addancestor (id: integer) add-descendant (id: integer) add-direct-senior (id: integer) add-directjunior (id: integer) delete-ancestor (id: integer) delete-descendant (id: integer) delete-direct-senior (id: integer) delete-directj unior (id: integer) related-roelidnumber9rid: *Roleid): integer get-ancestor ( ): * Roleidltem get-descendant ( ): * RoleidItem get-directjunior ( ): * RoleidItem get-direct-senior ( ): * Roleiditem combine-duplicated-role(r: & Role)

I Figure 5.5 Class Role Definition

getqrivilege-num: Given the access type, it retrieves this type of access permissions

this role has and retums the number of them.

get-allqrivilege-num: It r e m s the total number of access permissions this role

has, regardless of the access mode.

get-readlist: It r e m s the pointer that points to the Privilege object that stores read

access permissions of this role.

get-writelist: It retums the pointer that points to the Privilege object that stores write

access permissions of this role.

get-executelist: It returns the pointer that points to the Privilege object that stores

execute access permissions of this role.

get-memberlist: It retums the pointer to the first MemberItem object in the user list

of this role.

add-member: It adds a user pointed to by the parameter to the user list of this role.

delete-member: This h c t i o n deletes a user fiom the user list of this role. This

user's name is referred by the parameter.

has-equalqrivilege: This function checks if the role pointed to by the second

pararneter has identical access permissions of the type specified by the first

parameter as this role.

related-object: This function checks whether the role pointed to by the pararneter

pointer is related to this role.

operator-: Given a role, this fimction assigns the values of its data members to those

of this role. This should not be a self assignrnent.

directjunior: It checks if the given role is the direct junior role of this role. The

return value 1 represents "yes" and O represents "no".

direct-senior: It checks if the given role is the direct senior role of this role. The

return value 1 represents "yes" and O represents "no".

set-level: This function sets the vertical level of this role to the value specified by the

pararneter.

get-level: It retums the vertical level of this role.

add-ancestor: This member huiction adds the id of a role to the ancestral role id list

of this role.

add-direct-senior: This function adds the id of a role to the direct senior role id list

of this role.

add-descendant: This member function adds the id of a role to the descendant role id

list of this role.

add - directjunior: This function adds the id of a role to the direct junior role id list

of this role.

delete-ancestor: This member function deletes the id of a role from the ancestral role

id list of this role.

delete - direct-senior: This function deletes the id of a role from the direct senior role

id list of this role.

delete-descendant: This member fûnction deletes the id of a role from the

descendant role id list of this role.

delete - directjunior: This function deletes the id of a role fiorn the direct junior role

id list of this role.

related-roleid-number: This fimction returns the number of role ids in a related role

id list specified by the parameter. It actually retums the number of one kind of

related roles of this role.

get-ancestor: This function retums the pointer that points to the first RoleidItern

object in the ancestral role id list of this role.

get - descendant: This function r e m s the pointer that points to the first RoleidItem

abject in the descendant role id list of this role.

get-directjunior: This member fùnction returns the pointer to the first RoleidItem in

the direct junior role id list of this role.

get-direct-senior: This member function retums the pointer to the first RoleidItem in

the direct senior role id list of this role.

combine-duplicated-role: Given a duplicate role of this role, this function combines

them. The users assigned to the given role are added to the user list of this role.

and the given role is destnicted.

The Roleset Class

Roleset Iistrole: * RoleItem rolenurnber : integer levelnumber : integer MaxRole: Role MinRole: Role

Roleset ( ) -Roleset ( ) set-rolenurnber (number: integer) get-rolenumber ( ): integer set-levelnurnber (level: integer) get-levelnumber ( ): integer get-role-header ( ): * RoleItem link-role (r: & Role) deleterole(rid: integer) set-role-level ( ) get MaxRole ( ): & Role g e c ~ i n ~ o l e ( ): & Role search-role (nd: integer): &Role cornmon-senior ( ) cornmonjunior ( ) direc~relation ( ) relationship ( ) store-rolelist ( )

Figure 5.6 Class Roleset Definition

1. Definition: As previously introduced, roles are organized into a list. This class is

designed to hold this list and some information about this list. One of the private data

mernbers of this class is a role list. The other private data members are: the number of

roles in the role list, the MaxRole and the MinRole for ail the roles in the list and the

vertical level of the role graph to be generated for al1 the roles in the list. The

d e f ~ t i o n of this class is indicated in Figure 5.6.

2. Public Member Function Semantics

Roleset: This is the constnictor of class Roleset. It initializes a Roleset object with an

empty role list. Consequently, both the initial nurnber of roles in the role list and

the vertical level of the role graph are 0. The MinRole and the MaxRole are

initialized with id O and vertical level O. Their user list. privilege sets and

related role id lists are set to empty.

-Roleset: This is the destructor of the class Roleset.

setroleoumber: Given an integer, this member function sets the nurnber of roles in

Ihe role list of this Roleset object to this integer.

get - rolenumber: This îùnction r e m s the number of roles in the role list of this

Roleset object.

set-levelnumber: This function sets the vertical level of the role graph to be

generated fiom the role list of this Roleset object to the value specified by the

pararneter.

get-levelnumber: This function r e m s the vertical level of the role graph to be

generated from the role list of this Roleset object.

get-role-header: This member function retums the pointer to the first Rolehem

object in the role list of this Roleset object.

link-role: Given a reference to a role, this member fbnction links the role to the role

list of this Roleset object.

delete-role: Given an id of a role, this member function deletes the role fiom the role

list of this Roleset object.

set-role-level This function calculates the vertical level for al1 the roles in the role

list of this Roleset object.

get-MaxRole: This fùnction returns the MaxRole of this Roleset object.

get-MinRole: This fùnction retums the MinRole of this Roleset object.

search-role: It checks if there is a role in the role Iist of this Roleset object with an id

equal to the id given by the parameter. If a role is found, the fimction returns

the pointer to the role. Othenvise this function retums a nul1 pointer.

common-senior: This function identifies the MaxRole for all the roles in the role list

of this Roleset object. If no such role is found. one is created with al1 the

privileges of these roles.

cornmonjunior: This function identifies the MinRole for al1 the roles in the role list

of this Roleset object. If no such role is found, one is created with the cornmon

privileges of ail these roles.

direct-relation: This function analyzes the direct-junior and the direct-senior

relationships arnong the roles in the role list of this Roleset object.

relationship: This member function examines the ancestral and the descendant

relationships among the roles in the role list of this Roleset object.

store-rolelist: This member function stores the information of this Roleset object to a

file.

The Mem berItem Class

The RoleidItem Class

The RoleItem Class

1. Definition: These three classes could be defined through a template class called

Item. The definition of this template class is demonstrated in Figure 5.7. In this

structure, there is a pointer to another Item object. Another data member is used to

hold a Member object, a Roleid object or a Role object. We cal1 the object elemenr.

2. Public Member Function Semantics

Item: It is the default constmctor. It calls the default constructor of class T and

initializes the pointer to null.

Item(&T): Given a reference to an object of class T, this constructor assigns this

object to the element data member and sets the pointer to null.

-Item: It is the destructor of the class Item.

setelement: This member h c t i o n sets the elernent data member to the object

specified by the parameter.

1 Item <eisss T> I -

element: T next: *Item

- -

Item ( ) Item (m: &T) -Item ( ) set-element (m: &T) get-element ( ): &T get-next ( ): * Item add-next (n: * Item)

--

Figure 5.7 Template Class Item Definition

get-element: This member function r e m s the object of class T included in this

object.

get-need It retums the pointer to the Item object pointed by this Item object.

addpext: In this fùnction, this Item object is set to point to the Item object pointed

by the parameter.

Global Variables

1. homedirnum: integer

This variable is designed to keep the nurnber of home directories in the chosen

sub-systems. It determines the number of elements in the integer array of the

Privilege class.

2. homenarne: array of string

This array is used to store the simple narnes of the home directories in the

chosen sub-systems. The simple name of a home directory is the user name of the

account to which the home directory relates. The full pathname of a home directory is

the absolute pathname of this home directory.

3. roleid: integer

This integer is used to uniquely identify roles. Its initiai value is 1. The id of

the first role is set tol. After a role is generated, this integer is incremented by 1.

5.2 Steps to Fulfill the Requirements

5.2.1 Su b-system Choice

To fulfill this requirement, three steps are needed. First. fom the six sub-

systems. Second, prompt the user to choose sub-systems to be monitored. Third.

check the user's selection,

5.2.1.1 Form the Six Sub-systems

In chapter 4, we noted that on the research network of the Cornputer Science

Department of the University of Western Ontario. the home directories of real users

are located under six sub-directories of directory ksd. However. not al1 the directones

under these sub-directories are users' home directones. Under each of these six

directories. there are usually some directories for administrative purposes (such as

D O W and TT-DB under lcsdlgradl) and some for other purposes.

First of dl , we need to exclude the non-users' home directories. This couId be

done by filtering out the full pathnames of real users' home directories from the NIS

database passwd to six files by UNIX shell scripts. These six files are called sub-

system files. Each of these files only contains the home directories in one of those six

sub-directones. This implies that each of these files has one corresponding sub-

system. When the security of some sub-systems is monitored, only the directories in

the corresponding files are actually checked.

The module for this step is cdled Subsystern. Its interface routine looks like:

Routine names

form-subsy stem

Outputs Inputs Exceptions

5.2.1.2 Generate the Interface

Following, the user is prompted to select the sub-systems to be monitored using

the prompt in Figure 5.8.

The user is expected to enter several numbers between O and 5 followed by 6.

These numbers should be seperated by space(s) or return. If a 7 is entered. then the

RGM execution terminates. If a number not between O and 7 is entered. the exception

handler "menu-scope" should be cailed to tell the user to choose a number between O

and 7 to continue. If 6 is met, the RGM goes on to the next step. The narne of the

module for this step is Menu. The interface of this module looks like:

Please choose which sub-systems to be monitored. You can choose 1-6 subsystems.

O. Faculty 1. Graduate 2. Undergraduate 3. Staff 4. People 5. Project

6. Choosing completed 7. Exit

Routine names

menu

Figure 5.8 The Interface to Prompt the User for Sub-systems

5.2.1.3 Check the Selection

The parameter integer array is used to store user3 selection.

Outputs Inputs

int *

M e r 6 is entered, the RGM checks if the user has chosen some sub-systems. If

Exceptions

menu-scope

the user has, RGM goes on. Otherwise, it outputs the message "No sub-system has

been chosen" and r e m s to the interface menu. This step's module is called Choice.

Its interface routine looks like:

Routine names( Inputs 1 Outputs ( Exceptions

check-choice int *

The parameter integer array stores the user's selection.

5.2.2 Role Generation

There are three procedures needed to fùlfill this requirement. The first

procedure monitors the security of home directories. The second procedure assigns

values to global variables: homedimum and homename. n ie third procedure creates

roles.

5.2.2.1 Monitor the Security of Home Directories

This procedure monitors the security of the home directories in the chosen sub-

systems. The full pathnarnes of home directories in one of the sub-systems are

obtained fiom one of the six sub-system files. If any of the files can not be opened.

the exception handler "monitor-file" should be called to inform the user.

When monitoring home directories, their group owners and access permissions

are stored to file "filel" that will be used when constmcting roles. The monitored

home directories' simple narnes are filtered into file "file2". Afier monitoring. the

number of monitored home directories is calculated and outputted to file "file3".

The module for this step is called Monitor. Its interface routine looks like:

Routine narnes 1 Inputs 1 Outputs 1 Exceptions

monitor 1 int * 1 1 monitor-file

The parameter integer may stores the user's selection.

5.2.2.2 Assign Values to Global Variables

This procedure assigns values to the global integer homedirnum and the global

array of string homename. It reads the number of monitored home directories fiom

"file3" and assigns it to homedirnum. The simple names of those monitored home

directories are read from '-file2" and assigned to homename. If either of these two

files cm not be opened, the exception handler "global-file" is called. The module for

this step is called Global. Its interface routine looks like:

Routine names 1 Inputs 1 Outputs 1 Exceptions

glo bal-value I 1 global-file

5.2.2.3 Generate Roles

Put every group into a role - an object of class Role. The role's id is set after the

global variable roleid. The privileges included in the role are the access

permissions this group has to the home directories in the chosen sub-system(s).

The access permissions are acquired fiom file "filel". The narne of the user

assigned to the role is the same as the name of the group. Afier a role is created. it

is linked to the role list. It is done by calling the member function Iink - role of

class Roleset. Let's cal1 the role rl , the role list of an Roleset object list. The

basic algorithm of üiis member function is shown in Figure 5.9.

The duplicate roles refer to roles with the sarne privileges.

FOR (each role r2 in list)

IF (rl is a duplicate role of role r2)

THEN add the users of r l to the user list of r2

destroy rl

ELSE link rl to the end of list

ENDIF

ENDFOR

Figure 5.9 The Algorithm of Member Function Zink-role of Class Roleset

linkl = list

IF (link 1 != NULL)

THEN

WHILE (Iinkl != NULL)

link2 = the pointer to r2 which r l (pointed by linkl) points to

WHILE (link2 != NULL)

IF (r2 pointed by link2 isn't related to rl)

THEN link2 = the pointer to r which r2 points to

ELSE

construct a Roleid object whose id is equal to id of rl

construct a Roleid object whose id is equal to id of r2

add them to the descendant or ancestral role id list of cl and r2

according to the relationship between r l and r2

link2 = the pointer to r which r2 points to

ENDIF

E N D W I L E

link 1 = the pointer to r which rl points to

ENDWHILE

ELSE output "empty list"

ENDIF

Figure 5.10 The Algorithm of Member Function relationship of Class Roleset

IF ((the number of read privileges of r >= that of rl)

AND (the number of write privileges of r >= that of rl)

AND (the number of execute privileges of r >= that of rl))

THEN IF ((the read privileges of r l is junior to that of r)

AND (the write privileges of rl is junior to that of r)

AND (the execute privileges of rl is junior to that of r))

THEN return 1

ELSE return O

ENDIF

ENDIF

IF ((the nurnber of read privileges of r <= that of r l )

AND (the number of write privileges of r <= that of rl )

AND (the number of execute privileges of r <= that of rl))

THEN IF ((the read privileges of r is junior to that of rl )

AND (the write privileges of r is junior to that of rl )

AND (the execute privileges of r is junior to that of rl))

THEN retuni 2

ELSE return O

ENDIF

ENDIF

return O

Figure 5.1 1 The Algonthm of Member Function rehted-object of Class Role

M e r putting every group into a role, we check the relationships among these

roles. This is done by calling the member function relatiomhip of the class

Roleset. Let's cal1 the Roleset object roleset, the role list of roleset list and the

roles in list r. The aigorithm of this function is show in Figure 5.10.

Checking if two roles are related to each other is done by calling the rnernber

function related-objecr of the class Role. Let's cal1 this Role object r. the other

Role object rl . Its algorithm is shown in Figure 5.1 1. In this algorithm. the return

value O rneans that they are not related to each other. 1 means r is senior and 2

means r is junior.

Next the direct-junior and direct-senior relationships arnong these roles are

checked. This is carried out by calling the member function direcî-relation of the

class Roleset. The ids of the direct-senior roles of a role will be added to this

role's direct-senior role id list. The ids of the direct-junior roles of a role will be

added to its direct- junior role id list.

The main idea to check if a role rl is a role r2's direct senior role is that any rl 's

junior role must not be r2's senior role if rl is r2's direct senior.

The main idea to check if a role rl is a role r2's direct junior role is that any r l ' s

senior role must not be r2's junior role if rl is 1-2's direct junior.

Then the vertical levels of al1 these roles are determined by calling the member

function set-role - levez of the class Roleset. The algorithm of this function is

presented in Figue 5.12.

Next, we identify, or create, the MinRole and the MaxRole for the roles in the role

list by calling the member function common junior and cornmon-senior of the

class Roleset. If there is a role that is junior to every other role, then that role is

made MinRole. if there is no such role, then one is created with al1 the common

privileges of these roles. In this case, no user is assigned to this MinRoie. and its

level is set to the maximum vertical level of these roles, plus one. This MinRole's

direct senior roles are those roles without direct junior roles. If there is a role that

is senior to every other role, then that role is made MaxRole. Otherwise one is

created containing al1 the pnvileges of these roles. In the latter case, no user is

assigned to this MaxRole. The vertical level of it is set to 1 and the vertical levels

of dl the other roles should be incremented by 1. This MaxRole is the direct-

senior role of those roles without direct- senior roles. It is a special situation

when there is only one role in the role list. This only role is made MaxRole.

MùiRole is created with no pnvileges in order to make sure that the MaxRole and

the MinRole will not have identicai privileges. If they have identical pnvileges.

the role graph to be formed will be cyclic.

The module to this step is called Construct-role. Its interface routine looks like:

The parameter ifstream & is a file reference. It refers to the file that stores the

names of al1 the groups on the research network. The parameter Roleset * points to

the Roleset object that links the generated roles.

Routine names

construct - role

Exceptions Inputs

ifstrearn &, Roleset * Outputs

IF (a role does not have any direct senior role)

THEN the level of it = 1

ENDIF

i= l

WHILE (TRUE)

j=O

FOR ( d l the roles)

IF (for a role, the vertical level of one of its direct senior roles is i)

THEN the level of it = i+ 1

j++-

ENDIF

ENDFOR

i*

IF Cj = = 0)

THEN break

ENDIF

E N D W I L E

Figure 5.1 2 The Algorithm of Member Function se-le-levez of Class Rolese~

5.2.3 Role Graph Generation

The procedure that generates the role graph in this thesis will be based on the

prograrn Role Graph Generator (RGG) [17]. The RGG takes a role file. which stores

the information of roles. as input. To fulfill this requirement two steps are needed.

First, generate the role file. Second, generate the role graph.

5.2.3.1 Generate the Role File

Co-ordinating the Role Graph Generator and the aim of this thesis. we choose

the format of a role file as shown in Figure 5 . L 3.

The information of a role is presented in Figure 5.14.

Notes: (for Figure 5.13 and Figure 5.14)

1. The words in italics are keywords.

2. n i e roles with the sarne vertical level are outpuned in any order.

3. Every privilege, every user name, every role narne should occupy a single line.

1. The format of a privilege is the following:

read or write or execute the simple narne of a home directory

5. The name of MaxRole is MaxRole and the name of MinRole is MinRole. The

other roles' names are the same as their ids.

6. Because the RGG (Role Graph Generator) is designed to read only the direct

privileges of a role, only the direct privileges of a role are stored in the role file.

The procedure to generate a role graph should be able to calculate the effective

privileges of a role according its relationship with other roles.

According to the role file format, the information of the roles (roles in the role

list and their MaxRole and MinRole) is outputted to a role file sequentially by calling

the member function store-rolelist of the class Roleset. The module to this step is

called Rolefle. Its interface routines look like:

Routine names Inputs Outputs Exceptions

generate-rolefile Ro leset &

The o d y parameter is a reference to a Roleset object. The role file is based on

the roles contained in this object.

The vertical level of the role graph

Next Level

I

iVext Role

the information about MarRole

Next Level

the number of roies in this level

Next Role

the information about one of the roles in this level

- until al1 the roles in this level have been described

-

- This is repeated until al1 the levels with level No. smaller than the vertical level of the

role graph have been outputted.

Nexr Level

I

Next Role

the information about MinRole I

these levels are outputted according to their level No. from small to big.

Figure 5.1 3 The format of a role file

5.2.3.2 Generate the Role Graph

In this thesis, the role graph is generated by making some modifications to the

Role Graph Generator (RGG). RGG is an application in visual prograrnming

language TcVTk. Provided with a role file. it creates a role graph and administrates it.

Because the role graph management is not needed in this thesis. we remove the

administration fûnctions of the RGG. The RGG was written for the management of

databases originally, therefore it requests a database name in the role file and displays

the database narne in the role graph. Since, this thesis does not deal with the

management of databases. we need to rnake some modifications to the RGG.

the narne of the role

Privileges

direct read privileges

direct write privileges

direct execute privileges

Users

narnes of the users assigned to this role

Connects

, narnes of this role's direct senior roles

Figure 5.14 The information of a role.

5.3 Implementation of RGM The Role Graph Monitor software consists of 2 programs. The first prograrn.

called Role File Generator (RFG), written in the progmmming language C++ and

UNLX sheZZ scripts, fulfills the first two requirements for RGM and half the third

requirement - to generate a role file. The second prograrn. the Role Graph Generator

II (RGGII), a graphic interface written in the visual programming language tcl.

accomplishes the other half of the third requirement - to generate a role graph.

The executable code of RFG is contained in the following location:

/csd/grad/hua/thesis/program2/rfgg The source code of RGGII is contained in:

/gauUs8/student/ 1 994/hua/thesis/code.

See Appendix A for the user guide of RGM.

5.4 Summary This chapter provided the details regarding the RGM design and implementation

including the main data stmctures in RGM, the steps to fulfill the requirements for

W M and the implementation of RGM. The example results are presented in chapter

6.

Chapter 6

Experimental Results

6.1 Demonstration of Experimental Results

Through ninning the RGM, we c m generate a role graph for every sub-system

and every combination of those sub-systems. In this chapter. we demonstrate six

examples of experimental results. The following idormation will be illustrated in

every example:

The role graph generated by the RGM.

A picture of the information about the MaxRole.

A picture of the information about the MinRole.

A picture of the information about one of the other roles (roles except

MinRole and MaxRole in the role graph).

Figure 6.1 The Role Graph of Example 1

Example 1

The Role graph of this example is shown in Figure 6.1. In this role graph, there are

only two roles: MaxRoie and MinRole. This role graph is generated for the sub-

systems faculfy and people. There are 60 home directories in these two sub-systems.

However, only one role is generated. As a result, this role is made MaxRole. A

MinRole is created with empty pnvilege set and empty user Iist. The information of

MaxRole and MinRole is depicted in the next page.

Figure 6.2 The MaxRole of Example 1

Figure 6.3 The MinRole of Example 1

Figure 6.4 The Role Graph of Example 2

Example 2

The role graph of this exarnple is presented in Figure 6.4. Although this role graph

looks like that of example 1, they are different. It is produced for the sub-systems

faculty, staff; people and projeci. In total, there are 98 home directories in these four

sub-systems. Two roles are generated. It happens that one role is junior to the other

role. The junior role is designated MinRole and the senior role is designated

MaxRole. Therefore, both the privilege set and the user list of MinRole are not empty

in this example. The MaxRole and the MinRole are displayed in the next page.

Figure 6.5 The MaxRole of Exarnple 2

Figure 6.6 The MinRole of Example 2

Figure 6.7 The Role Graph of Exarnple 3

Example 3

The role graph of this exarnple is given in Figure 6.7. It is created for sub-systems

faculfy, graduate, staff and people. The total nurnber of home directories in these four

sub-systems is 137, and there are only 3 roles generated. There is no common senior

role or common junior role arnong these 3 roles. Therefore, a MaxRole is created

with al1 the privileges of these 3 roles, an empty direct privilege set and an empty user

list. A MinRole is created with d l the cornmon privileges of these 3 roles and an

empty user list. The locations of these 3 roles in the role graph are decided by their

vertical levels. The following two pages illustrate the MaxRole, the MinRole and role

3.

Figure 6.8 The MaxRole of Exarnple 3

Figure 6.9 The MinRole of Example 3

Figure 6.10 Role 3 of Example 3

Figure 6.1 1 The Role Graph of Example 4

Example 4

The role graph of this example is given in Figure 6.1 1. This graph represents the sub-

systems undergraduate, stafi people and projecl. There are 92 home directories in

these four sub-systems. The number of roles generated is also 3. However, there is a

common junior role - role 1 in this exarnple. Therefore, this role is made the

MinRoIe. A MaxRole is created with al1 the privileges of the 3 roles. an empty direct

privilege set and an empty user list. The following two pages display the

demonstration of the MaxRole, the MinRole and role 2.

Figure 6.12 The MaxRole of Exarnple 4

Figure 6.1 3 The MinRole of Exarnple 4

Figure 6.14 Role 2 of Exarnple 4

Figure 6.15 The Role Graph of Example 5

Example 5

The role graph of this example is presented in Figure 6.15. It is produced for the sub-

systerns faculty, graduate, undergraduate, stafl and people. The total nurnber of

home directories is 143. F o u roles are generated. Role 1 is a common junior role for

role 3 and role 4. Role 2, role 3 and role 4 are not related to each other. There is no

cornmon senior role or common junior role for dl these 4 roles. Consequently. a

MaxRole is created with an empty direct privilege set and an empty user list, and a

MinRole is created with al1 the common privileges of these four roles and an empty

user list. The MaxRole, the MinRole and role 3 are displayed in the follorving two

pages.

Figure 6.16 The MaxRole of Example 5

. . . . . . . . .

Figure 6.1 7 The MinRole of Example 5

Figure 6.18 Role 3 of Example 5

Figure 6.1 9 The Role Graph of exarnple 6

Example 6

The role graph of this exarnple is shown in Figure 6.19. It is created for al1 the six

sub-systems. The total number of home directories is 18 1 and 5 roles are generated.

There is no cornrnon senior role or common junior role for these 5 roles. A MaxRole

is created with an empty direct privilege set and an empty user list. A MinRole is

created with al1 the common privileges of these 5 roles and an empty user list. The

content of the MaxRole, the MinRole and role 4 is exhibited in the following two

pages.

Figure 6.20 The MaxRole of Example 6

Figure 6.2 1 The MinRole of Example 6

Figure 6.22 Role 4 of Example 6

6.2 Conclusions

The above examples show that not only do role graphs help the system

administrators of a UNIX system visualize the security of users' home directories. but

also simplie the security issue. For example, in example 6 there are 181 home

directories monitored. Without the role graph, the system administrators would need

to change directory six times, look through 181 lines of the result of command Is -ig.

and consider those groups that are not the owner group of a home directory 18 1 times.

They will quickly "lose their minci" because of the heavy workload. However. with

the role graph the system administrators only need to click on the seven roles and

easily get a clear picture of the security status.

Beyond a doubt, the role graph is a powerful tool to monitor the security of

users' home directories in a UNIX system such as the university research network.

The research network is characterized as a UNIX system with a medium number of

home directones. Many of the roles generated fiom groups will have identical

pnvileges. This is because the traditional UNIX file system offers al1 the groups that

are not the owner group of a home directory the same permissions to this home

directory. Even for a UNIX system with a large number of home directories. the

number of roles generated will not likely be able to ovenvhelm the role graph. Thus.

it is feasible to employ the role graph to monitor the security of home directories on

large UNIX systems with a great number of home directories.

In conclusion, the role graph is an effective tool that can help the system

administrators to monitor the security of users' home directories in a W I X system

easily and efficiently.

Chapter 7

Conclusions

In this chapter, we summarize the contributions of this thesis and point out some

possible directions for future reiated work.

7.1 Con tributions

This thesis was motivated by the importance of keeping users' home directories

secure in the UNIX system and by the enthusiasm of applying the potentiai immense

power of the Role Graph Model.

The aim of this thesis is to use role graphs to monitor the security of users'

home directories in the UNIX system. That is, this thesis combines UNIX and role-

based access control by using role graphs to model the access permissions of users'

home directories in a UNIX system.

A piece of software called the Role Graph Monitor (RGM). w-ritten in C++.

UNLY shell scripts and [cl, has been developed to acheve the aim of this thesis.

Considering the main objective and the research environment of this thesis, we have

identified the requirernents for the RGM. These requirements are sub-system choice.

role generation and role graph generation.

Based on the identified requirements, we have provided the design and the

implementation for the RGM. As part of the RGM design, we have presented the

structuring and primitives for the concepts about role graph mode1 using object-

oriented concepts. The concepts about role graph model include user. privilege, role.

senior role, junior role, direct-senior d e , direct-junior role, Mado le and MinRole.

We aiso have described the steps to achieve those requirements. The algorithms for

the key steps have been illustrated.

We provided some experimentai results. These results demonstrate that the role

graph is a powerful and effective tool to monitor the security of users' home

directories. Through using role graphs, monitoring the security of home directories in

the UNIX system has become an easier task.

This thesis has provided a foundation for fiture research in the area of role-

based protection for the security of home directories in UNIX.

7.2 Future Work

One possible area for future research is combining the traditional UNIX file

access control method with role-based access control to improve the security of home

directories. In this thesis, the role graphs visualize the access permissions of the home

directories. Through these role graphs the system administrators c m analyze the

usee' home directory security in the system. They can find which group is not tmsted

enough to have the privileges it is having and carry out corresponding procedures.

Because of the inherent problems of the traditionai UNIX file access control

mechanism, it is difficult for the system administrators to give different access

permissions to a home directory for the groups that are not the owner group of this

home directory. Further work could be done on combining the traditional UNIX file

access control method with role-based access control to help system administrators

overcome this difficulty through role graphs.

Other aspects of &tue work c m be pursued in the following areas:

Investigating uses of the RGM. The experimental results on the research network

of the Computer Science Department of UWO suggest that RGM visualizes the

access permissions of the home directones with great success and effectiveness.

Further work could be done on investigating possible applications of the RGM in

other environrnents.

Improving security of the RGM. At present, any one can run the RGM as long as

he/she has execute permission to the executable code of the program WG (Role

File Generator) and read permission to RGGII's (Role Graph Generator II) source

code. Work could be done to permit only the super-users of the system to access

and execute the RGM.

Changing the way in which the roles are constructed in the RGM. In this thesis.

every group is put into one role; that is. the user-role relationship is established

first and then the privileges are assigned to the roles. However. in reality. the

role-permission relationship is generally pre-defined and then users are assigned

to the pre-defined roles. The reason is that a role represents a job function within

the organization that descnbes the authority and responsibility conferred on a user

assigned to the role [6] . Work could be done on constmcting roles by pre-

defining the role-permission relationship.

Enhancing the data structures related to the role graph model. In this thesis. we

use object-oriented concepts to model the concepts related to the role graph

model. such as role, privilege. user, etc. The structures designed in this way work

well in RGM, but they are not optimized. Further work could be done on

strengthening these structures to make them more effective.

Add search functions to the Role Graph Generator II. Functions that allow users'

to search if a given role has a certain privilege or a certain user could be added to

the Role Graph Generator II.

Appendix A

The Usage of the RGM

In order to use a role graph to monitor the security of the home directories in

some sub-systems, the user must first run RFG to monitor the security of these sub-

systems and create a role file. Then run RGGII and let it open that role file. The steps

are as follows:

Generating the Role File

Invoke WG by typing

rfg

on the cornrnand line of any machine on the research network.

Then the user will see the prompt as shown in Figure 5.8.

The user is expected to enter numbers between O and 5 followed by 6. The

numbers should be separated by space(s) or retum. If a 7 is entered. then the

RFG execution terminates. If a number other than O to 7 is entered. the user

will be told to choose between O and 7 to continue. If 6 is entered. the program

checks if the user has chosen some sub-systems. If this is the case . RFG goes

on. Otherwise, it terminates with the output message "No sub-system has been

chosen" and lets the user make choices again.

After a while, the user is asked for the name of the role file using the

following prompt:

Piease input a name for the role file:

Upon temination of RFG, a role file is created.

Generating the Role Graph

To launch the role graph, on obelix (in the Computer Science Department at

the University of Western Ontario) type

wish4.1

on the comrnand line.

The user will see that an empty window pops on the screen and the prompt of

obelix changes to %. Now the user is in the Tcl environment. The next step is

to load the source code for RGGII. Type

source code

Now the user should be able to see a window entitled Role Graph Generator

on the screen.

In that window. select the Open option fiom the File menu to open the role

file generated in the laçt step. A new role graph will appear in that window.

Then the user can view every role in the role graph. The role graph can also

be sent to a laser printer.

To quit the RGGII. select the Exit option fiom the File menu in that window.

The window will disappear and the obelix prompt will return to its nomal

symbol.

REFERENCES

1. Paul W. Abrahams and Bruce R. Larson, "Unix for the impatient", second edition. Addison- Wesley Publishing Company, 1996.

2. David A. Curry, "UNIX System Security: a Guide for Users and System Administraton", Addison-Wesley Publishing Company, 1992.

3. Jerry Cashin, "Open. distributed users tightening Unix security". Software Magazine. Vol. 14, NO. 1, Jan. 1994, pp. 8 1 -9 1.

4. M. Nyanchama and S. Osborn. "n i e Role Graph Mode1 and Conflict of Interest". 1996. (Personal communication)

5 . M. Nyanchama and S. Osbom, "Access Rights Administration in Role-Based Security Systems," Database Securiy VUZ: Slatus and Prospects. J . Biskup et al.. eds.. Elsevier North-Holland, 1994, pp. 37-56.

6. R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. "Role-Based Access Control Models." Computer, No. 29. Feb. 1996. pp. 38-47.

7. Laura K. Reid, " Using Roles To Represent Security In SQL". The University of Western Ontario's Master Thesis. August 1 995.

8. Michael R. Ault. " UNIX System Administrator's Cornpanion." John Wiley & Sons, Inc., 1996.

9. Christoph Braun, YJNIX System Security Essentials". Addison-Wesley Publishing Company, 1995.

10. Patrick Wood. "A Loss of Innocence", UNLX Review, Vol. 6, No. 2. Feb. 1988. pp. 36- 42.

11. Jim Johnson and Sidnie Fert, "Open security an oxymoron?", Sofmare Magazine. Vol. 12. No. 11, 1993, pp. 71.

12. Mark G. Sobell. "UNIX System V: Practical Guide". the Benjamin/Curnmings Publishing Company, Inc., third edition. 1995.

13. R.S. Sandhu, "Lattice-Based Access Controls Models," Computer, Vol. 26. No. 1 1, NOV. 1993, pp. 9-19.

14. NISTI, "An Introduiiiün to Role based access control-" NIST CS1 Bulletin on RBAC, http:// hissa.ncsl.Nst.gov/nistbul/cs 195- 1Z.txt

15. NIST?, iRole based access control (RBAC): Features and Motivations." http:// hissa.ncsl.nist.gov/rbac/newspaperlrbac . h W

16. D.J. T'homsen, "Role-Based Application Design and Enforcement." Compter & Secuity, IV: Starus and Prospects, 1 99 1. pp. 1 5 1 - 1 68.

17. C. Zhang, " A User Interface for Role-based Security," The University of Western Ontario's Fourth Year Required Thesis Project, A p d 1996.

18. Eduardo B. Femandez Jie Wu and Minjie H. Femandez "User Group Structures in Object-oriented Database Authonzation," Database Security VIII: Status and Prospects. J. Biskup et al.. eds., Elsevier North-Holland, 1994. pp.57-76.

19. J. Rurnbaugh et. al., Object-Oriented Modeling and Design. Prentice Hall Inc.. 1991.

IMAGE EVALUATION TEST TARGET (QA-3)

APPLIED - IMAGE. Inc = 1653 East Main Street - -. , Rochester. NY 14609 USA -- == Phone: 71 6/4829300 -- -- - - Fax: 71 6/28&5989

O 1993. Appiied Image. Inc.. Ail Rigtits Re6erved