an authorization mechanism for unix-based cooperative environments

i~fo~tio~ Sy.~mns Vol. 16, No. 5, pp. 509-535, 1991 03~~379/91 $3.00 + 0.00 Printed in Great Britain. AI1 rights reserved Copyright Q I99 1 Pergamon Press pit

AN AUTHORIZATION MECHANISM FOR UNIX-BASED COOPERATIVE ENVIRONMENTS

M. G. FUGINI,‘~ R. BELLINZONA* and G. MARTELLA’

‘Dipartimento di Elettronica, Politecnico di Milano, Piazza da Vinci 32, I-20133, Milano, Italy

2Universita di Milano, Milano, Italy

(Receded 7 June 1990; in revised form 6 June 1991)

Abstract-The extension to the UNIX protection mechanisms proposed in this paper aims at supporting controlled resource sharing and more flexible and tine-grained discretionary protection in UNKX-based cooperative work environments, such as collaborative software development environments (SDEs).

In these environments, the project members need to share programs, data and tools on a temporary basis and according to their roles in the project. Run-time updatable decentralized authorization allows the group to implement separate work areas administered by different project responsibles.

The proposed system is based on tools for specifying the cooperative SDE protection policies at the level of project members. Decentralized authorization is achieved through the authorizer role.

System tools, integrated in the UNIX kernel, implement the run-time access checking. The protection system architecture and a prototype, based on a UNIX-like kernel restructuring

approach, are described.

Key words: Di~retionary autho~~tion, decentralized authorization management, administration tools, security specifications, kernel restructuring

1. INTRODUCTION

Because of its evolution in “friendly” environments, standard UNIX [l-3] mainly supports protection policies aimed at maximized resource sharing [4].

The increasing use of UNIX in various operative and applicative environments, such as software development environments (SDEs) and information systems (ISs) [5,6], requires a more sophisti- cated management of privileges based on need-to-know policies and on system administration fQciZitie~ to decentralized authorizers [?-9f.

For example, in SDE, users dynamically share tools, programs and project information, and are grouped into teams on the basis of project tasks, and are coordinated by one (or more) project leader who is responsible for dynamically assigning resources to the project participants [lo, 61.

The enhancements that have been proposed to UNIX protection mechanisms are mainly oriented to the development of formally provable secure kernels [l 1, 121 or to the interpretation of Department of Defense (DOD) multilevel mandatory policies [13, 141. Recently, standards for UNIX-based open systems have been proposed by various standardization institutions, aimed mainly at providing compatibility between applications and connection interfaces in networks and distributed systems; these standards include security recommendations [15-l 91.

The extensions described in this paper address discretionary authorization policies for cooperative SDEs. Sharing requirements considered by the system are: resource sharing on a temporary basis, specification of the limitations that appfy to sharing (e.g. all the project members who need to access the project source files in write mode), the possibility to address special users in a “grant privilege” operation (e.g. grant READ documentation to user usr-idl), or to limit the propagation of privileges ([9,20]) to specific users or user groups.

In particular, the aims of the system are: (1) to provide fine protection grunuiarity ; and (2) to support flexWe and manageable resource-sharing policies of access from various roles to project resources (files, directories, volumes, documentation) on the basis of the minimum set of privileges necessary to carry on software development tasks.

The first aim, that is, to implement protection granularity at a finer level than in UNIX discretionary mechanisms, is obtained by allowing users to grant and revoke privileges to spec@

tAlso at University of Brescia, Italy.

IS 16P-D so9

510 M. G. FUGINI et al.

users or to an arbitrary set of users. The delegation of the grant privilege is also included, to provide a controlled propagation of grant privileges. Conversely, in standard UNIX, since only the owner can issue the chmod command, a granted access right cannot be transferred any further by the recipient of the privilege.

The second aim, that is, to implement flexible sharing policies, is achieved by extending the concept of system administration and by providing tools for run-time management of protection. Various authorizers are responsible for managing different sets of resources; this allows security administration tasks to be assigned, for example, to managers of groups of people who participate in a sub-task of a software project. Authorizers are organized hierarchically: each can nominate dependent authorizers, transfer to them a set of resources to be administered, and set the protection policies for these dependent authorizers. In cooperative work environments [lo], such logically decentralized resource administration policy mirrors the work distribution and hierarchies. Decentralized authorization is not concerned with privileges in a physically distributed underlying architecture, which are objects of security standardization (see, [18,21] for an overview).

The protection system is centered around a set of user-interface tools for the specification of protection policies [22] by the authorizers. These tools are based on a high-level language (SSL-Security Specification Language) used by the authorizers to specify protection policies on the system resources and management of user-privileges.

The corresponding run-time access controls are based on the enforcement module, located within the UNIX kernel. The standard UNIX kernel has been modified to interact with the new services provided by the enforcement module. ACLs (Access control lists) protection structures are associated to files [23]. The ACL mechanism is coupled to the standard flag-based protection mechanisms of UNIX; system call requests are intercepted by the enforcement module and checked against the ACLs.

New protection commands are provided to the authorizers and users. The focus of this work is on the specification environment, where privileges can be defined

dynamically and where the consistency of these privileges can be verified run-time upon definition of new protection policies. Accordingly, the ACL mechanisms are illustrated to show what information for run-time update of security policies is included in the ACLs and how it is managed. Examples are given referring to application development in UNIX-based SDE.

The contents of the paper are as follows. In Section 2, we give an overview of the UNIX basic protection mechanisms and briefly recall the extensions that have been proposed in the literature.

Then, we describe the proposed protection system. In Section 3, the basic features of the system are described, and the protection model at the basis of the system is illustrated. In Section 4, the system architecture is presented; then, the section presents the user-interface tools and, in particular, the specification language and the checks performed on the specifications. The run-time access control tools are presented in Section 5. The enforcement module for run-time access checking is described in Section 6. System implementation issues are presented in Section 7.

2. UNIX PROTECTION MECHANISMS

The UNIX system protection mechanisms [24] support user authentication at login time and access control based on user identity.

In standard UNIX a careful discretionary management of users’ access privileges on system objects is the basic way of realizing a secure environment.

2.1. Basic mechanisms

In standard UNIX, users are uniquely identified by their login names. In order to log onto a UNIX system, users get over an authentication procedure that checks the login name and the password.

Each user can be inserted in the definition of one or more UNIX groups. A user can be associated to a limited set of groups at a time, and can switch group membership during his login session through the newgrp command.

UNIX-based cooperative envjronments 511

Each process has an associated user and group identifier describing the initiator of the process and his membership group at process creation time.

The security reievant information associated withJiles and directories consists of the owner and owner’s group identifiers and of 11 protection flags.

The owner and owner’s group of a file correspond, respectively, to the user who created the file and the membership group of the user at file creation time; both identifiers can be changed by the owner through the chown and chgrp commands.

Nine protectionflags specify the permitted access modes of the owner, of the owner’s group and of all other system users. These flags are divided into three triples, each corresponding to a user category.

Access modes to regu~ar~les are: read (flag R), write (gag W), execute (flag X). Only the first two modes apply to devices. When associated to a directory, the X flag is the search right, necessary to execute any access operation on the files contained in the directory; the R flag regulates the listing of the file names of the directory; the W hag is related to directory updates, that is, file insert and remove operations.

Two other flags, named setuid and setgid flags and identified by U and G characters, are used for protection of executable files [2]. The execution of a program whose setuid flag is “on” causes the created process to acquire the program owner’s identifier. The setgid flag has the same effect on the group identifier.

The access checking procedure first computes the category of the accessing user by matching the user and group identifiers of the accessing process with the owner and owner’s group identifiers of the accessed file. The access is allowed if the flag of the access mode and selected from the flag triple corresponding to the user category is “on”.

Therefore, the access privileges available to a process depend on the user and group identifiers associated to the process.

A special user (the super-user) has all privileges without restrictions. The UNIX discretionary access control mechanism is based on the chmod command and on the

setuid/setgid feature. The chmod command allows, by changing the status of flags, the owners to grant and to revoke

access rights on their files to the users in the owner’s group and/or to all other users. The setuidlsetgid mechanism allows for the development of programs that implement their own

discretionary policies [2]. For example, setuid programs owned by the super-user are used to control the access to sensitive

data, such as kernel data. The execution of these programs lets users temporarily acquire super-user privileges; however, all accesses are mediated in a controlled way by setuid programs thus preventing users from circumventing system security. Programs like ps, passwd, mail, mkdir, etc. are developed this way.

The setuid/segid feature allows also the development of protected subsystems. such as mail systems, database system, or software packages that do not want their data (e.g. account files, statistics etc.) to be accessed by users from without the package. These programs are owned by the user and/or group owner of the data to be protected.

2.2. Enhancements to the basic mechanisms

The enhancements proposed to the standard protection mechanisms mainly aim at developing formally verifiable systems, or at interpreting the DOD security policies in centralized en~ronments [13] and in decentralized architectures [25].

Generally, the approaches to secure UNIX have followed two main strategies:

1. Building a new kernel upon which a UNIX emulator operates: the kernel performs basic operating system tasks and its security is formally proved; the emulator includes a UNIX system call interface, which is built on the basis of the kernel services, and therefore allows packages to use UNIX features;

2. Restructuring and extending a UNIX kernel: the security mechanisms of the UNIX kernel are changed and extended in order to meet additional security policies, such as multilevel policies.


The main advantage of the first approach is that the system security can be formally proved. The second approach allows one to develop more efficient systems in a shorter time.

The first approach was successfully followed in the development of the Kernelized Secure Operating System Ill] and of UCLA Secure UNIX [12]. An example of the UNIX kernel restructuring is Secure Xenix [14]. Here, the mandatory security policies specified in the Bell-La- Padula security model are interpreted; moreover, the discretionary security policies are extended through an ACL-based mechanism that allows file owners to specify access privileges for specific users or groups; finally, the new protection mecha~sms coexist with the standard mechanisms.

For distributed urc~itectures, standards for secure application environments have been proposed following security and general standards [15,19,261. One relevant aspect addressed by these studies is authorization privileges distribution which is mainly based on the concept of security domains. “Privilege servers” are coupled to authorization mechanisms in order to ensure the logical identity of users, Often, the access control system receives from the authorization mechanism a “ticket” used as a privilege attribute certificate [21]. The proposal presented in this paper deals with secure application development within the limits of one ECMA domain [17], and addresses discretionary privilege propagation within the domain. In particular, our protection services are located at the end-system view.

3. THE PROTECTION SYSTEM: BASIC FEATURES AND PROTECTION MODEL

The extended protection system enhances the UNIX d~scret~anary mec~an~ms by allowing users to grant and revoke privileges to specific users or to arbitrary sets of users.

The delegation of the grant privilege is also included to provide a controlled propagation of grant privileges; in standard UNIX, since only the owner can issue the chmod command, a granted access right cannot be transferred any further by the recipient of the privilege.

For system administration, various authorizers are responsible for managing subsets of project resources. Security administration tasks are decentralized and can be assigned, for example, to managers of groups of people who participate in a sub-task of a software project.

The protection system comprises:

User-interface to&s-These are centered around the Security Speci~cation Language (SSL) through which the authorizers specify the protection policies. Such tools are: an SSL cumpiie$, a consistency checker and an updater, which propagates the modifications made to SSL specifications to the statements affected by the change; finally, a mapper translates the SSL specifications into low-level protection structures accessed run-time by the enforcement module.

Run-time access control tools-These are centered around an enforcement module responsible for access checking upon user-requests. The module is located within the UNIX kernel according to a kernel restructuring approach.

The user’s activities that are supported and monitored by the protection system during system operation are the following:

Protection S~cificatio~The authorizers collect the protection and sharing policies about the resources they manage directly. Then, the authorizer formalizes these policies in SSL and submits them to the protection system.

The authorizers assign privileges to owners and to dependent authorizers about resources which they do not administer directly. Also these privileges are specified in SSL. Dependent authorizers are then created.

Monitoring of the protection state of system resources-Run-time, users can grant and revoke privileges to other users through the discretionary privileges assigned to them. Authorizers and users can check the protection of the system resources; in particular:

-authorizers can see who are their dependent authorizers; -authorizers and owners can display all privileges on objects they administer or own; they

can also see the access history on these objects.

UNIX-based cooperative environments 513

Modljkation of the protection state of system resources-The authorizers can update the SSL specifications in order to reflect the changes in protection policies. Dependent authorizers can be revoked from their administrative role by parent authorizers.

The system is based on a protection model; the availability of a model [22] allows the system designers to prove the adequacy of the design and implementation to the client’s protection policies. Moreover, the consistency of the protection policies can be formally checked and maintained.

In the following of this section, we describe the basic elements of the protection model; details on the model can be found in [27,28].

3.1 The protection model

3.1.1. Subjects. Subjects are the users; they are identified by their login names. Each process acquires all the privileges of the user who executes it or, for setuid/setgid programs,

of the owner/owner group of the file that stores the program to be executed. Users can be grouped in active entities and in groups. An active entity contains a set of users who are functionally similar, for example, because they

have analogous tasks in a software project. Active entities can acquire privileges; a user has all the privileges assigned to the active entities of which he is a member.

Groups correspond to the standard UNIX groups; however they are not subjects and cannot acquire privileges. A group is composed of a set of users who collaborate to a common project and whose privileges must not propagate to other system environments.

Groups are used to distinguish users’ privileges on the bases of users’ roles. Each user can be included in the definition of one or more groups corresponding to the roles he can perform; like in standard UNIX, each user can be a member of only one group and can perform only one role at a time. This feature is realized by linking privileges to group membership: group switching causes the change of the privileges available to users.

3.1.2. Objects. Objects are regular files, directories and special files (devices). Objects can be grouped in passive entities. Each object can undergo all the operations authorized

for the passive entities of which it is a member. This grouping concept enriches the standard UNIX directory mechanism: passive entities group

objects that are related for security reasons, independently of their physical organization in directories.

Objects can be shared or private. Shared objects are administered by authorizers. They have no owner, and authorizers must

specify all privileges of users theron. Their protection is enforced on a close system basis [4]. Shared objects are the resources used within a user group. The group leader administers, as an

authorizer, the resources of the group: he acknowledges the needs of the group members, specifies the resource sharing policies and assigns the appropriate privileges (need-to-know policy) to the users of the group.

Private objects are administered by their owners; ownership gives the user all the privileges on the owned object. Some authorizers are responsible also for private objects: they can forbid some access privileges and can restrict the propagation of access privileges. Owners can execute on their files all the operations that do not contradict the prohibitions specified by authorizers. Thus, the protection of private objects is enforced on an open system basis [4].

Examples of private objects are those portions of the file system that start at the users’ home directories.

Only authorizers can classify objects as private or shared. They also specify the owners of private objects: the creation of a private object does not automatically imply the acquisition from the creator of the object ownership.

Only authorizers can move objects from the category of shared objects to that of private objects and vice versa. They can also modify the ownership of private objects.

3.1.3. Privileges. Privileges of subjects on objects are of two types: access privileges and discretionary privileges.

Access privileges represent access modes to objects. They are specific for each category of objects.


The privileges that apply to regular files are: read, write, exec; those applying to devices are: read and write; privileges applying to directories are: read, search, add-entry (insert a file), delete-entry (remove a file).

Discretionary privileges are the modes of transferring access privileges. Discretionary privileges are the following:

-grant (~1, ~2, p, 0): subject sl can grant to subject s2 the p privilege on the o object. sl can revoke p from s2 provided that s 1 is one of the privilege grantors: s2 retains p on o if this privilege was granted by multiple sources.

-revoke (s 1, ~2, p, 0): subject s 1 can revoke from subject s2 the p privilege on the o object. The p privilege is totally revoked from s2 on o, independently of multiple grants. s 1 need not be a grantor of the revoked privilege, nor have the privilege to grant it.

-delegate (s 1, ~2, p, o, S): subject s 1 can delegate to the s2 subject the privilege to grant to the S set of users the p access privilege on the o object; analogously to the grant privilege, it allows its holder also to abrogate a previously granted delegation.

-abrogate (s 1, ~2, p, o, S): subject s 1 can abrogate from subject s2 the privilege to grant the p access privilege on the o object to the S set of users. The delegated privilege is completely abrogated from ~2, independently of previous delegate operations on o. The access privileges granted by s2 using the delegate privilege are not automatically revoked; however, the abrogator acquires the privilege to revoke these privileges.

3.1.4. Special subjects: the authorizers. Some users, named authorizers, are responsible for the administration of sets of resources.

Authorizers belong to a hierarchical structure. Each authorizer receives the resources to administer, represented as portions of the file system, from a parent authorizer and can create new dependent authorizers by assigning them a portion of (or all) his resources. The UNIX root is the root of the authorizers tree: by default, it administers the whole file system.

The hierarchy of authorizers can be represented as a tree. Figure 1 shows an example of a tree of authorizers with the corresponding administered resources.

The A0 authorizer is initially responsible for the administration of the whole file system. Then, he nominates A 1 and A 2 as dependent authorizers and assigns them the resources starting at the /prjs and /adm directories, respectively. In turn, A 1 nominates A 11 and A 12 as authorizers responsible of the resources in the /prjs/alpha and /prjs/beta directories, respectively.

The authorizers’ hierarchy must be loop-free. Each authorizer has only one entry in the authorizers’ hierarchy and only one parent authorizer. An authorizer is identified by a user name and an administrative role name (e.g. a project name

in a software engineering environment, an organization area name in an industrial department). The role name is assigned by the parent authorizer and is unique for each user. Hence, a user can receive resources from different parent authorizers and can hold different administrative roles; a user can, however, perform only one administrative role at a time.

The (user-name, administrative_role_name) pairs univocally identify one authorizer. Figure 2 shows user and role name assignment to the generic authorizer names listed in Fig. 1;

moreover, a new authorizer A 3, is created by AO. A 3 corresponds to usrid3, who is thus responsible for the beta and gamma projects.

k _7c!ADM Fig. 1. Tree of authorizer hierarchy.


Fig. 2. (User-Role name) assignment to authorizer hierarchy.

Authorizers have the following special privileges:

-to classify administered resources as shared or private and to specify the owners of private objects;

-to impose restrictions on the rights of dependent authorizers; -to specify access and discretionary privileges on shared resources and to impose restrictions

on the rights of the owners of private resources; these specifications should not violate the restrictions imposed by parent authorizers;

-to issue the authorize and unauthorize commands (see below) through which the authorizers’ hierarchy is managed.

The privileges to modifv the authorizers’ hierachy are the following:

authorize (Ai, Aj, O), where ,4j = (sj, rj)---Ai can nominate subject sj as a dependent authorizer whose task is to administer the resources belonging to the 0 set; sj can administer 0 only in the rj administrative role. A new node, labeled ,4j, and an arc from Ai to Aj are created in the authorizers’ hierarchy tree.

The creation of a dependent authorizer implies the loss for the creator of all administrative privileges on the transferred resources; all protection specifications related to transferred resources become constraints for the dependent authorizer. Since dependent authorizers cannot violate these specifications, the authorizers define the protection and sharing policies that dependent authorizers should meet in the administration of received resources.

As a consequence of the resource transfer upon creation of an authorizer, each object is administered by only one authorizer.

unauthorize (Ai, Aj), where Aj = (sj, rj )---authorizer Ai can revoke from subject sj the authorization task Aj related to the rj administrative role. Aj must be linked with Ai in the authorizers’ tree and the revocation procedure applies automatically also to all authorizers deriving from Aj: all arcs (and nodes reached) are removed from the authorizers’ tree, starting from Ai.

When the unauthorize command is executed, the revoker gets back the administrative privileges on the resources transferred to the revokee; he also receives back all the protection specifications possibly defined by the revokee.

3.2. Model rules

The model elements in Section 3.1 are structured in the model in the form of rules. A rule has the following form:

(subject, privilege, object); predicate,

where “predicate” is a logical condition on the validity of the privilege held by the subject on the object. Predicates can be built on values of system variables, on access history, on the access request context. We will illustrate a set of possible predicates when describing the SSL.

The model rules are grouped into two categories: positive and negative rules. Positive rules define permitted privileges of subjects on objects; they are used to administer shared

resources and to specify the privileges that owners or dependent authorizers cannot remove.


Fig. 3. Static graph of user usridl. Fig. 4. Propagation of privileges: dynamic graph.

Negative rules define forbidden privileges; they are used to administer private resources, by restricting the privileges automatically acquired with ownership, and to impose restrictions to the privileges of dependent authorizers.

Rules are further divided into static and dynamic. Static rules define permitted or forbidden access privileges. They are represented in a static graph.

For example, the static graph of Fig. 3 illustrates that usridl can read the /usr/prjalpha/Fl file and can write all files belonging to entity E 1; users who belong to E2 are prevented from reading the /usr/prjalpha/Fl file (dotted-line arrow, representing a negative rule).

Dynamic rules define permitted or forbidden discretionary privileges. Dynamic rules are graphically represented in a dynamic graph. For example, the dynamic graph of Fig. 4 illustrates that usridl can grant to the members of E3 the privilege to add and delete the files contained in the directories belonging to entity E4. usridl can also delegate to the members of ES the privilege to grant to users in E7 and E8 the privilege to search the directories in E6.

The rules are used to check the consistency of the model, as it will be illustrated in Section 4.1.4.

4. PROTECTION SYSTEM ARCHITECTURE

The architecture of the protection system is illustrated in Fig. 5; it shows the environment of one authorizer (e.g. authorizer 1). Its modules are illustrated in the following.

User interface tools:

The SSL compiler-Checks the syntax of the protection specifications entered by the authorizer using SSL and stored in SSL files. New statements are merged with SSL files included in the library of the authorizer. Conflicts in the specifications (e.g. subjects with the same names) are resolved through unique identification. The consistency checker-derives the structures of the protection model from the specifications contained in the library, deduces the access rules that implicitly derive from a set of specifications, and then checks the statements for inconsistencies and redundancies. The updater-Identifies the operations to be executed to keep the run-time information i.e. the contents of ACLs and of the entity file (see the run-time tools in Fig. 5) consistent with library changes. The identified operations are stored in the update jle.

When an SSL file is recompiled, the updater matches the new with the existing specifications and computes the operations that remove the specifications included only in the old version, in order to insert only the new specifications and to change the entities which are present in both versions with different definitions; then, it removes the old specifications from the library. The mapper-executes on rhe ACLs and the entity file (the entity file contains a system- level description of the system subjects and objects) the operations described in the update files. The mapper uses the new UNIX kernel (see Fig. 5) services to access the ACLs and entity file contents.

Run-time access control tools:

The enforcement module-Checks the run-time access operations on files, implements the discretionary privileges and consequently updates the protection specifications. It uses the contents of the ACLs, of the History Lists (HLs) and of the entity file. It is located in the UNIX kernel because it interacts with the execution of kernel services.

UNIX-based cooperative en~ro~men~ 517

consistency checker

updater k-4 fihraries othn authorizers

USER-INTEZWACE TOOLS

entity map auth. 1

1 delegate

\ ACLs HLs

UNIX KERNW . __-... .--

RUN-TIME ACCESS CONTROL TOOLS

Fig. 5. Protection system architecture.

Figure 5 also shows the PteW cu~~un~s that are available in the system. These commands are the following:

The sslcatalog command-allows the authorizer to display the protection specifications contained in his library. The rmssZ command-Removes all the protection specifications contained in an SSL file and calls the updater; the updater computes the operations necessary to remove from the ACLs and from the entity file all the specifications contained in the removed file.

The auth and ~na~th cumman~-manage the authorizers’ hierarchy. They operate both on the SSL files and on the libraries of the involved authorizers, in order to transfer the protection

specifications relating to the resources whose administration is transferred. They do not modify the information contained in ACLs and in the entity file.

An up~te~le is created, containing a description of the new ids assigned to transferred entities. The grant, revoke, delegate, abrogate commands-Represent the high-level interface to the corresponding kernel services. These are UNIX commands issuable by any user during a shell session. The rightview and histview commands-Allow users to display the contents of ACLs and HLs, respectively.

In the following of this section, the user-interface tools are described. The run-time access control tools are illustrated in Sections 5 and 6.


4.1. User-interface tools: the specijication of protection requirements

Protection requirements of a UNIX-based work environment are specified by the authorizer(s) using the Security Specification Language (SSL). This language is the basis for the user-interface tools. This section presents the SSL (Section 4.1.1); then, it describes how SSL specifications are handled by the user-interface tools (Section 4.1.2) and illustrates the language features for management of the authorizer’s hierarchy (Section 4.1.3); some examples of authorization management are given. Finally, the analysis of the SSL specifications is discussed (Section 4.1.4).

4.1.1. The Security SpeciJication Language (SSL). Specifications in SSL consist of a set of statements that describe the elements of the protection model. The constructs of SSL relate these elements to UNIX elements: users, user-groups, files, directories, commands.

The basic types of SSL clauses for defining the model elements are now illustrated.

The entity clause-An SSL entity is a set of subjects/objects to which the same protection policies apply and can therefore be grouped in the same specifications. Entities are containers of subjects/objects or both.

The entity contents can be defined as: a list of UNIX elements; a UNIX system expression; a reference to another entity; a combination of the previous modes through the union (+), intersection (*) and difference (-) set operators.

Each entity has a unique name. UNIX elements correspond to basic subjects and objects of the protection model. They can be used for entity definitions, as in the following examples (SSL keywords are in italics):

entity {usridl, usrid2, usrid3) hasname junior-users; entity {/bin/vi, /binled} hasname edit-tools

A system expression is a sequence of UNIX commands whose execution produces a list of UNIX elements. This mechanism allows a dynamic description of the elements represented by entities. Upon system events that modify the result of the evaluation of an expression, the protection system re-executes automatically the expression commands and updates the entity contents. Commands that can be specified within system expressions are a subset of all UNIX commands. They include:

-commands that abstract the contents of a file (e.g. awk, grep, cat, join, sort); -commands that abstract the contents of a directory (e.g. 1s); -commands that return a list of the elements satisfying some conditions included in a

portion of the file system (e.g. find).

Examples of entity definitions containing system expressions are the following:

1. entity “awk -F: ‘{print $l}’ /etc/passwd” hasname allusrs; 2. entity “is/bin” hasname bin-progs; 3. entity “find /usr/usridl -type r -print” hasname usr Miles;

The allusrs entity contains the login names of all users, obtained by selecting the first field of each line in the password file; when the /etc/passwd file is updated, the allusrs entity is automatically kept up to date.

The bin_progs entity groups all files contained in the /bin directory and is updated every time a new file is inserted in the /bin directory or an old one is removed.

The usrl_files entity groups all regular files contained in the portion of the file system starting at the /usr/usridl directory; the entity is updated every time an insert/remove operation involves the /usr/usridl directory or one sub-directory.

An entity acquires dynamic features also when its contents include references to dynamic entities. For example, the following SSL statement:

entity bin-progs + “1s /usr/bin” hasname allcmds;


defines a new entity (named all_cmds) that contains all files of the /bin and /usr/bin directories; the alLcmds entity is updated every time a file is inserted or removed from the /usr/bin directory or when the binprogs entity (defined in Statement 2 above) is updated.

The dynamic features of an entity are sometimes undesired and can be turned off: a system expression or a reference to an entity preceded by the “ # ” character is replaced with the result of the expression evaluation or with the entity contents, respectively.

For example, the following statement:

entity “1s /usr/bin” - # “1s /usr/bin” hasname new_cmds;

defines the new_cmds entity which contains all files inserted (and not removed) in the /usr/bin directory from the moment when the statement was submitted to the protection system.

The entity statement also allows for the definition of objects as shared or private.

The action Claus-The SSL action clause allows authorizers to group the access and discretionary privileges.

An action contains a list of model privileges (see Section 3.3) or previously-defined actions. For example, the SSL statement:

action {read, search, add-entry, delete_entry)hasname all-dir-acts;

defines the all-dir acts action which includes all privileges applicable to directories; users endowed with all these privileges are specified as being globally endowed with the all-dir-acts privilege.

The rule change-The model rules are specified in SSL using the rule clause. SSL rules are static or dynamic, depending on whether they contain an access or a discretionary

privilege. Rules are also divided into positive and negative, depending on whether they permit or forbid

a privilege.

Examples

Considering entities and actions defined in the clauses above, the following protection specifications can be given:

1. all-usrs can exec all _cmds; All users contained in the alLusrs entity can execute the programs specified in all-cmds entity.

2. use-id1 can all_dir_acts /usr/prjgamma; usrid to execute all actions specified in the all_diracts action on the /usr/prjgamma directory.

3, usr_id2 can grant usr_id3, usrid read /usr/prjalpha/modl.c; usr_id2 can transfer to usr-id3 and usr_id4 the READ privilege on the shared file /usr/prjalpha/modl .c containing C source code.

4. usrid cannot grant usrid write usr2__fIles. usr_id2 is not enabled to transfer to usrid the privilege to update the files contained in the usrUles entity {this entity contains the files owned by usrid2).

Since rule definitions can contain entities with dynamic features, protection policies can be entered dynamically and incrementauy. When the contents of a dynamic entity is updated, the protection system updates the privileges affected by the rules that reference the entity. For example, through rule 1 above, a new system user automatically receives the “execute” privilege on the files included in the allcmds entity.

Predicates-Rules can contain a predicate that defines a (set of) conditions on the rule. When the predicate is false, the access mode specified in the rule is forbidden. Conditions are evaluated run-time by the enforcement module.

Predicates can be built on system variables (such as current date, weekday and time), or on the terminal from which the access request is issued. Moreover, predicates can make an access decision dependent on the system access history. In fact, the protection system stores information about

520 M. G. FUGINI et ai.

access operations executed in the system; this information includes the access parameters, the group and terminal associated to the process that requests the access, the program that originated the process, the date and time of the access request, the execution status. Information about past accesses can be used to constrain some privileges.

Example

1. usridl capr delete-entry /tmp if user lastaccess (create) on $Jie = usr-idl; 2. usr-id:! can exec ~~r/prjalpha~alphap~ if date lastaccess (read) of usrid on

/usr/p~alpha~alphaman > = May 1, 1991.

Rule 1 allows user usridl to remove a file from the [tmp directory only if usridl is the file creator. Rule 2 allows usrid to execute the alphapgm program if the last reading time of usrid on

the program manual (alphaman) occurred after May 1, 1991. 4.1.2. Submitting the SSL specifications to the protection system. As shown in Fig. 5, each

authorizer has an associated environment where the protection specifications about the resources administered by that authorizer are stored. In an SDE, this corresponds to having various workareas containing private resources of the individual developers. Files of SSL statements are common text files editable with text editors (e.g. ed, vi).

No relationships hold among SSL statements specified by different authorizer. Security s~cifications are submitted to the SSL compiter, checker and

to the mapper (see Fig. 5). These tools are called sequentially and perform the following actions:

-checking of the syntax of SSL statements and reporting of errors such as the use of non-valid UNIX elements, references to elements that are not members of any administered resources, the definition of inapplicable entities and actions, etc.;

-checking of the consistency between the statements of the authorizer and those of his parent authorizers; violations to the administrative rights specified by the parent authorizer are reported;

-mapping of the SSL statements into low-level protection mechanisms for run-time access control.

4.1.3. managing the hierarchy of authurizers. The authorizers are provided with commands for managing the hierarchy of authorizers. In order to obtain the authorizer’s privileges, after the login procedure, an authorizer executes the authprj command where he specifies one of his administrative roles, such as project leader, team member, programmer, client. Authorizers are then enabled to issue the AUTH and UNAUTH commands illustrated in the following:

The AUTH command-An authorizer can create dependent authorizers. The command parameters are the name (user-id and administrative role) of the dependent authorizer and the list of the resources transferred to him. Resources are specified as portions of the file system.

The UNAUTH command-Dependent authorizers are removed. The command parameter is the name of the dependent authorizer (user and admins~ative role name).

All protection specifications of the revokee, and those of the authorizers dependent on him, are removed backwards to the command issuer: all SSL files contained in the specification environments of the revokees are placed into the specification environment of the revoker.

We show the use of AUTH and UNAUTH through some examples,

Example I

In a cooperating project team, the project manager Al delegates to a programmer usridl the management of the project workareas starting from a given directory, say “beta”. However, the programmer keeps being prevented from managing the project documentation and the project management information.

This policy is entered by A 1 by specifying a new authorizer identified by (usridl, beta); this is entitled to supervise the files and directories starting at the /usr/beta directory, excluding those


appended to the /usr/beta/doc and /usr/beta/info directories. The corresponding command issued by A 1 is:

AUTH usridl ,beta /usr/beta - /usr/beta/doc-/usr/beta/info

causing the SSL specifications of A 1, and related to the transferred resources, to be moved into the workspace of the dependent authorizer.

Example 2

The project leader splits the team members into three groups (two analysis teams and one team of programmers) and assigns them the visibility of different programs and documentation.

The corresponding specifications entered by the project leader are:

entity “1s /usr/prjalpha” hasname alpha-tiles; entity “1s /usr/prjbeta” hasname beta-files;

these statements partition the file system starting at /usr into two environments. Then, the three members groups are defined as follows:

entity {usridl , usrid2) hasname alpha-team; entity (usrid2, usrid3, usrid4) hasname beta-team; entity “cat /usr/info/programmers” hasname programmers;

The privileges are assigned as follows:

programmers can read alphafiles; programmers can read beta-files; alpha-team can write alpha-files; beta-team can write beta-files;

4.1.4. Analysis of SSL protection specifications. Specifications in SSL are submitted to the SSL compiler and consistency checker (see Fig. 5) for syntax and semantic checking. The specifications are matched against the specifications belonging to the whole environment of the submitting authorizer. This environment includes the specifications of parent authorizers. The consistency and redundancy checks aim at finding SSL rules that state different protection requirements for the same UNIX resource; redundancy in the specifications is minimized through detection of repeated specifications; detection of violations to the restrictions imposed to the capabilities of authorizers is also checked.

Consistency checks are based on the protection model. Some of the checks on the model are briefly described in the following:

Building the protection model structures-The model rules, and their representations in the form of static and dynamic graphs (see Section 3.2), are built starting from the SSL “rule” statements and using the entity statements.

In the graph construction, checks are executed on the contents of SSL entities. For example, let us consider the entities defined by these SSL specifications, describing some

users and resources of the “alpha” project (programmers, leader, manuals, workareas):

entity “awk -F ‘(print $I}’ /etc/passwd” hasname all_usrs; entity usridl hasname alpha-leader; entity (usrid2, usrid3) hasname alpha-programmers; entity alpha-leader + alpha-programmers hasname alpha-team; entity alLusrs - alpha team hasname notalphamembers; entity “find /usr/prjalpha - type r - print” hasname alpha-files; entity “1s /usr/prjalpha/man” hasname alpha-man; entity {/usr/prjalpha/man/refman} hasname alpha-refman; entity {/usr/prjalpha/man/tutorial} hasname alpha-tutorial;


Fig. 6. Privilege graphs for consistency checking.

From these statements, an entity relation graph, which represents the contents of, and relationships among, entities is derived. The graph is depicted in Fig. 6; nodes represent model entities and arcs represent relationships between the contents of entities (or lack of relationships, represented by dotted-line arcs). Containment relationships are shown as labels on the arcs.

The static and dynamic graphs of the model, which show the system access and discretionary rules, are then built. As an example, consider the following specifications:

entity (usrid , usrid2, usr_id3} hasname beta-team; entity usridl hasname beta-leader; entity “find /usr/prjbeta -type r - print” hasname bettiles; entity “1s /usr/prjbeta/man” hasname beta-man; betateam can read beta-files; beta-leader can write beta-man;

These produce the static graph shown in Fig. 7, where fine arcs denote rules that have been derived by the system, and barred arcs correspond to rules constrained by a predicate.

The derived rules represented on the static graph of Fig. 7 can be also described by the following SSL statements, where the $user and $file keywords specify the accessing user and the accessed object, respectively:

betaleader can read bettiles; beta-team can read beta-man; betaleader can read beta man; beta-team can write beta-man if $user = beta-leader; beta-leader can write beta files if member $jile of betaman; betateam can write beta-files if $user = beta leader and member $file of beta-man;

Other consistency and redundancy checks regard conflicts between positive and negative rules, between static and dynamic rules, and inconsistencies relating to ownership.

Fig. 7. Static graph with derived rules.


The protection system reports as redundant speci$cutions those related to the following cases:

1. Two entities linked with the equality relation and specified by the same authorizer. 2. Two rules related to the same permission or prohibition with the same entities as

parameters and specified by the same authorizer. Derived rules are not used in redundancy checks and two rules are not reported as redundant when they have different constraints.

Upon detection of inconsistent specifications, the protection system reports the incorrect SSL statements. These must be manually modified by authorizers and resubmitted to the protection system. Redundancy reports are warnings.

TOOLS: MAPPING THE SPECIFICATIONS INTO PROTECTION MECHANISMS

SSL specifications are stored in the protection system in different formats and at various levels. Initially, they are grouped in text files as SSL statements. As seen in Section 4, the SSL compiler

represents the specifications in a library, one for each authorizer. Information contained in a library is checked for consistency upon each compilation, as

described in Section 4.1.4, and is used when specifications are moved between different authorizers. Library information is further processed to be associated to lower level structures that are

accessed run-time by the enforcement module. In this section, we describe how the SSL statements, for example relating to a file, are translated

by the mapper into rules, and then stored into the ACL associated to the file. An ACL gives a complete picture of the protection specifications about a file: it includes the SSL

specifications entered by the authorizers and the privileges granted on a discretionary basis by users. It also includes the description of the system events whose occurrence can modzyy the protection specifications. These events are of the following three types:

-modifications to the contents of entities involved in rules; -discretionary privileges issued by users; -modifications to SSL specifications issued by authorizers.

The system keeps the ACL contents up-to-date with event occurrences. In Section 5.1, the organization of ACL contents is described; then, in Sections 5.2-4, updates

to ACL upon system events are illustrated.

5.1. ACL contents

SSL entities can be classified as static or dynamic. The contents of static entities is fixed at the time these entities are entered into the protection system. The contents of dynamic entities change when system events modify the result of the evaluation of system expressions used to define them. Each access operation on a file therefore needs checking if this operation corresponds to an event that modifies the contents of some dynamic entities, in order to re-evaluate the definition of the affected entities and store their new contents in the entity file. The protection system computes the descriptions of the events that modify dynamic entities from the definition of the contents of these entities (on the basis of the contained system expressions or of the ones used in referenced entity definitions). Then, it stores each event description in the ACL of the file; this ACL will be updated to reflect the entity updates.

The descriptors stored in the ACL for automatic entity updates have the following general format:

Event (action) IMPLIES UPDATE ENTITY (entity) DEPTH (level)

when (action) is executed upon the ACL-protected file, the contents of (entity) must be re-computed.

The (level) field specifies the depth of propagations of the update information.


Some examples of information for automatic entity updates are the following (we also report the corresponding entity definitions):

1. entity “awk -F: ‘{print %l}’ /etc/passwd” husname allusrs;

ACL of /etc/passwd:

EVENT write IMPLIES UPDATE ENTRY alLusrs DEPTH 0

2. entity “1s /bin” hasname allcmds;

ACL of /bin:

EVENT add entry IMPLIES UPDATE ENTITY allcmds DEPTH 1 EVENT delete-entry IMPLIES UPDATE ENTITY allcmds DEPTH 1

The descriptions for automatic ownership update have the following format:

EVENT UPDATE ENTITY (entity) IMPLIES UPDATE 0 WNER (user) DEPTH (level)

When the contents of (entity) change, the protection system updates the ownership of (user) on the basis of the objects belonging only to the new contents of (entity) and of those belonging only to the old contents. The (level) field is analogous to the (level) field of the entity update descriptors.

The basic contents of ACLs is represented by access rules. An SSL rule containing a UNIX element as an object is directly represented in the ACL of the element.

When the object of a rule is a static passive entity, the protection system stores the rule in the ACLs of all the files belonging to the passive entity.

When the object of a rule is a dynamic passive entity, besides the previous operations, the protection system stores some information for automatic update of the rule, whenever the contents of the passive entity is updated.

Rules are represented in the ACLs according to the following format:

(origin) RULE (rule)

where (origin) denotes how the rule was specified: in fact, a rule stored in an ACL can derive from an SSL rule (origin = SSL) or from an automatic rule update operation (origin is omitted) or from a grant or delegate privilege (origin =user grantor-name).

(rule) is an internal representation of the SSL rule. The descriptors for automatic rule updates have the following format:

EVENT UPDATE ENTITY (entity) IMPLIES UPDATE RULE (rule) DEPTH (level)

When the contents of (entity) changes, the (rule) is removed from the ACLs of the files belonging only to the old entity contents and is inserted into the ACLs of the files belonging only to the new entity contents. The (level) field is analogous to the corresponding field in the entity and ownership update descriptors.

For example, the update information derived from the following SSL rules:

1. entity

(/usr/prjalpha/man/refman, /usr/prjalpha/man/tutorial} husnume alpha-man;

2. alpha-team can read alpha-man;

is the following:

ACL of /usr/prjalpha/man/refman and of /usr/prjalpha/man/tutorial:

SSL RULE alpha-team can read alLusrs can exec allcmds;

ACL of the /bin directory:

EVENT UPDATE ENTITY alLcmds IMPLIES UPDATE RULE allusrs can exec DEPTH 1;


ACLs of all files contained into the /bin directory:

RULE allusrs can exec usridl cannut grant usrid read usrl-.files;

ACL of the directories contained in the portion of file system starting at the /usr/usridl directory:

EVENT UPDATE ENTITY usrlfiles IMPLIES UPDATE RULE usridl cannot grant usrid read DEPTH maxdepth;

ACL of all files and directories starting at the /usr/usr_idl directory:

RULE usridl cannot grant usrid read.

5.2 update of ACLs upon entity ~od~~~ution~

Upon the execution of each access operation the protection system executes some operations for automatic protection spec@cation updating.

In particular, the ACL associated to the file involved in the operation is searched for entity update descriptors whose action field matches the operation; each entity listed on the entity field of the descriptors that satisfies the previous condition is marked for update. The definitions of the contents of marked entities are re-evaluated; the new contents are stored in the entity file.

The ACL is searched for rule update descriptors whose entity field matches one of the re-evaluated entities; for each matching description, the rule specified in the descriptor is removed from the ACLs of the files members only of the old contents of the descriptors-related entity and the same rule is inserted into the ACLs of file members only of the new contents of the involved entity.

For example, let us consider the following SSL statements:

entity “find /usr/prjalpha -type r -print” hasname alpha-files owlzer alpha-leader; alphateam can read alpha files; alphateam can grant all-usrs read alpha-files;

The contents of all the ACLs of the directories starting at the ~usr/prjalpha directory is the following:

EVENT add-entry IMPLIES UPDATE ENTITY alpha-files DEPTH maxdepth EVENT delete-entry IMPLIES UPDATE ENTITY alpha-files DEPTH maxdepth EVENT UPDATE ENTITY alpha-files IMPLIES UPDATE OWNER alpha-leader DEPTH maxdepth EVENT UPDATE ENTITY alphafiles IMPLIES UPDATE RULE alpha-team can read DEPTH maxdepth EVENT UPDATE ENTITY alpha-files IMPLIES UPDATE RULE alpha-team can grant all_usrs read DEPTH maxdepth

When the /usr/prjalphaJman/newref file is created, the definition of the alpha._files entity is re-evaluated and the /usr/prjalpha/man/newref is inserted into the contents of this entity. Besides, the following information is automatically stored in the ACL of the /usr/prjalpha/man/newref file:

OWNER alpha-leader RULE alpha-team can read RULE alpha-team can grant allusrs read

Upon creation of a new directory (e.g. /usr/prjalpha/notes) in the portion of file system starting at the /usr/prjalpha directory, the definition of the alpha-files entity is also re-evaluated. Since here the new contents equals the old one, no ownership or rule update is performed.

The ACL of the /usr/prjalpha/notes directory inherits all update info~ation associated to the ACL of the parent directory with depth > 1 (in this case, all the information above).

IS 16/s-E


5.3. Update of ACLs due to discretionary privileges

When a grant privilege on a file is issued, a new rule is inserted into the ACL of that file, If two users grant to the same user the same privilege on the same file, two rules that differ only in the origin field are inserted in the ACL of the file. For example, if usridl and usrid grant to usrid the privilege to read the /usr/prjalpha/man/refman file, the ACL of this file contains the following information:

1. USER usr_idl RULE usrid can read 2. USER usrid RULE usrid can read

When a user revokes a previo~ly -grantedpriv~lege, the rule that specifies the revoked privilege and that was discretionarily introduced by the same revoker is removed. With reference to the previous example, if usridl revokes usrid from reading, the /usr/prjalpha/man/refman file, rule 1 is removed; usrid maintains the read privilege because of rule 2.

When a revoke privilege is issued, all the discretionary rules that specify the revoked privilege are removed, no matter which users were the grantors.

For example, if usridl revokes usrid from reading the /usr/prjalpha/man/refman file, both rules 1 and 2 above are removed.

When a delegate privilege is issued on a file, a rule is inserted into the associated ACL. If two users delegate the same privilege to the same user on the same file, two rules are stored

in the ACL. The revocation of a previously-granted ~legation causes the rule that specifies the delegated

privilege, and that was discretiona~Iy introducted by the revoker, to be removed. The revocation of a delegation through the abrogate privilege causes instead all the rules derived

from the delegated privilege to be removed. The revocation of a delegation does not cause the revocation of the privileges granted with the

delegation: the specification of the grantor in the rule that represents these privileges is, however, changed to the user who revokes the delegation. This user acquires the right to revoke the privileges granted with the delegation.

With reference to the previous example, if usridl abrogates from usrid the privilege to grant to usrid the right to read the /usr/prjalpha~man~refman file, without the abrogate privilege, the ACL of the /usr~p~alpha~man/refman file remains the following:

USER usridl RULE usrid can grant usrid read USER usr-idl RULE usr_id3 can read USER usrid RULE usrid can read

5.4. Update of ACLs due to changes of SSL specijications

The process of mapping SSL specifications into the ACLs and into the entity file proceeds as follows:

-the definition and the contents of each entity are inserted into the entity file; -the descriptions of the events that cause the contents of the dynamic entities to be updated

are stored into the related ACLs; -the ownerships related to static passive entities are assigned to the file members of the entity

contents.

When an SSL file is modl~ed by the authorizer and is resubmitted to the protection system, information about differences in the specifications is used to keep the contents of ACLs and of the entity file updated.

Entities, ownerships and rules included only in the new version of a SSL file are inserted into the ACLs and into the entity file following the procedure described here above.

Entities, ownerships and rules included only in the old version of a SSL file removed from ACLs and from the entity file.

The removal of an SSL rule can cause the conditions that allowed the discretionary grant of some privileges to fail: if the privilege represented by the removed rule cannot be derived from other protection s~~ifications, the protection system also removes all the privileges granted using the removed rule.


6. RUN-TIME ACCESS CONTROL: THE ENFORCEMENT MODULE

The protection system must ensure that each access operation in the system conforms to the protection specifications formulated by authorizers and users.

Each access request directed to the UNIX kernel is intercepted by the enforcement module of the new UNIX kernel and checked on the basis of the information contained in the ACLs and in the “entity” file.

In the new kernel, the new protection mechanisms coexist with the standard mechanisms described in Section 2.1; objects which are not explicitly involved in any protection specification of authorizers are protected with the standard mechanisms. All other objects have an associated ACL and access is enforced using the ACL contents.

Each ACL-protected file has also an associated HL (History List) containing information about the access history of the file.

This section describes how the kernel services provide access control for basic system operations (Section 6.1), and presents the architecture of the enforcement module (Section 6.2).

6.1. Kernel services for jle system operations

61.1. File read, write and execution. A read, write or execute operation on a file can be performed only by holders of the read, write or exec privilege on that file, and the search right on all the parent directories of the file.

For flag-protected files, the privilege is checked through the standard mechanisms as described in Section 2.1.

For ACL-protected files, the operation can be executed if:

-the requester is the file owner and the ACL of the file does not contain a rule that prevents the owner to execute that operation;

or

-the access request is made by a user other than the file owner and the ACL of the file contains a rule that allows the user to execute the operation.

Checks about read and write operations on a file are performed upon “file open”. This operation requires the access mode to the file to be specified: UNIX ensures that a file opened, for example, in read mode can undergo only read operations.

When all write operations on a file have been performed and the file has been closed, the protection system checks whether an update to the protection specifications is required by consulting the update information contained in the ACL of the file.

An information item about all the read, write and execute operations on one file is always added to the HL of that file.

6.1.2. File creation. File creation requires the write privilege on the directory where the file is inserted, if this directory is protected with standard flags, or the add-entry right, if the directory is protected with ACL structures. In the second case, the add-entry privilege must be specified by an SSL rule. If the creator is not the directory owner, or no negative rules forbid the addentry privilege to the directory owner, an “add-entry” rule must exist. The search right on all parent directories of the file is also required.

The creation of a directory requires the same privileges above. If the directory where the file is inserted is protected with standard mechanisms, the file inherits

this standard protection mode and the creator becomes the file owner. If the file is created in an ACL-protected directory, the new file inherits this protection mode. The ACL of the new file automatically acquires some protection specifications if the creation

operation matches with the descriptions of entity update events that cause the new file to be inserted on the contents of some entities and some information about ownership and rule updates dependent on the updated entities.

The owner of the new file is therefore derived from automatic ownership updates and can differ from the creator. If no ownership update information matches, the new file becomes a shared file.


When a directory is created, its ACL acquires all information for the automatic entity, ownership and rule updates contained in the ACL of the parent directory whose depth > 1; the depth value is decreased by one if < > maxdepth.

Upon creation, history information is inserted into the HL of the new file (or directory) and in the HL of the directory where the file is inserted.

The recreation of an existingfile requires also the right to remove the old version of the file (see the following).

6.1.3 File removal. The removal of a file from an ACL-protected directory requires the delete-entry right on the directory (this can be acquired automatically by ownership or can derive from a protection specification). The removal of a file from a flag-protected directory requires the write right on the directory.

If the removed file has an associated ACL, the protection system deletes from the ACL information about ownership, and the privileges discretion granted and removable by the issuer of the removal.

‘ACLs are definitely removed when they are empty. The contents of the HL associated to the deleted file is always removed; information about the

removal operation is inserted into the HL of the affected directory. 6.1.4. File link. A link to aflag-protected$le, when the new file also acquires standard protection

mode is allowed upon the access privilege to access the link origin file and the privilege to create the new file (named link file).

Users’ privileges on files never increase upon a link to the file: UNIX stores only one information item about the flags, the owner and owner’s group; the classification of a user as “owner, member of owner’s group, other” does not change when using a link file other than the link origin file; the same applies to the owned privileges, which do not change.

For link operations to an ACL-protectedfile, a symbolic link (analogous to that of some UNIX versions) is created. The link operation can be issued only by the file owner, provided that he has at least the read privilege on the owned file and that ownership is acquired also on the new file, or by the UNIX root. The privilege to create the new file is also required.

The new file gets the ACL protection mode and no relationship exists between its ACL and the ACL of the origin file: a symbolic link makes the sharing restricted to file contents.

The removal of a link origin jile causes the removal of all the files linked to the removed one. 6.1.5. Discretionary privileges. Privileges on the files protected with standard mechanisms can

be changed by the owner with the chmod operation. This operation can also be used to set and to reset the setuid and setgid flags on all files.

Chmod can also operate on a newflag, denoted with the “A” character. This flag has status “on” ACL-protected files and “off” on flag-protected ones. It allows for changing the protection mode of a file.

The owner of a flag-protected file can associate an ACL to his file by setting the A flag on the file with the chmod operation. All privileges specified by flags are, however, lost and the file is made shared; the new ACL automatically inherits some protection specifications, analogously to what happens upon creation of a new file. The RWX flags on an ACL-protected file are always reset. The translation from an ACL-protected mode to flag-protected mode is not allowed.

Privileges associated to an ACL-protected file can be changed by users with the grant, revoke, delegate and abrogate operations; the restriction specified by the authorizer has to be matched. A grant or delegate operation can be issued when one of the following conditions is true:

-the requester is the file owner and no protection specification forbids the operation; -the requester is not the owner and a protection specification permits the operation.

A revoke or abrogate operation can be issued when one of the following conditions is true:

-the requester is the file owner and no protection specification forbids the operation; -the requester is not the owner and a protection specification permits the revoke or abrogate

operation; -the requester previously granted, with a grant or delegate operation, the privilege to be

revoked or abrogated, respectively, and no protection specification forbids the operation,


of ACL-protected file is specified by authorizers with SSL Statements, The &own

operation cannot be used to this purpose and can be applied only to flag protected files.

6.2. The enforcement module

The architecture of the enforcement module (see Fig. 5) and the interaction of the module with the other UNIX kernel functions are shown in Fig. 8.

UNIX processes use kernel services by issuing system call requests. All services of the standard UNIX kernel are also supported by the new kernel; the protection aspects of some of them have been modified as described above. New system calls are introduced to implement those protection- related tasks that could not be integrated within old services.

The new system calls implement the following tasks:

-Discretionary privileges. The grant, revoke, delegate and abrogate system calls support the discretionary grants and revocations performed by processes.

-Direct ACLs access. The mapper program and other packages change the contents of ACLs by directly accessing them. The acl system call returns to processes that perform protection administrative tasks a jile descriptor for access the ACL associated to a file; this system call is thus analogous to the open one. Processes manage the contents of the “opened” ACLs through the same system calls used to manage the contents of files. In order to access the ACLs, processes must know about the ACL structure and must get synchronized with the concurrent update of ACLs in order to preserve the linked list of the ACL information description.

-Direct HLs access. Analogously to ACLs, HLs can be accessed directly by special programs through the hist system call. This system call returns a file descriptor to access the contents of the HL associated to the file specified as call parameter with the usual file management system calls.

-Entity manager control. The entity system call provides protection administrative processes the facility to communicate special information to the enforcement module that manages entities. It is described in the following of this section.

The new UNIX kernel (Fig. 8) intercepts all the system calls through its system call interface. Some system calls (e.g. open, read, write) are partly executed as traditional system calls (using the old system services depicted in Fig. 8), partly using the new system services of the enforcement. Other system calls (e.g. grant, delegate, acl) are executed as new system services of the enfo~ement.

The module of the enforcement of Fig. 8 perform the following tasks:

--the access control module checks access requests; it consults the ACL of the accessing file in order to forbid or to permit each request; it uses the services of other portions of the enforcement module;

-the new system seruices module executes the new security system calls (with the exception of the entity call described below);

--the constraint evaluator module evaluates the predicates associated to rules; the constraint specified in SSL are mapped by the updater into instructions of a simple stack machine and stored into ACLs with related rules;

PROCESS UNIX KERNEL ENFORCEMENT FIL.E

j ~~~~~

Fig. 8. Enforcement architecture.


-the history manager module searches the HLs for information to be used in the evaluation of predicates; it adds history information to HLs;

-the entity manager module interacts with the entity file; it maintains an entity buffer containing the definitions and contents of the more recently referenced entities; it implements a virtualization of the space needed to store entities into main memory; its tasks include the checks of file and user membership against the entity contents, the re-evaluation of entity definitions and the execution of the entity system call; this system call allows processes to communicate to the entity manager that some changes in the entity file have been made or that the contents of an entity stored in the entity buffer must be saved in the entity file.

-the specljication updater module checks whether an operation involves some dynamic specifications. It computes the number of the entities to be updated and then invokes the entity manager for execution of the actual entity update operation.

7. SYSTEM IMPLEMENTATION ISSUES

Experimentations of the protection system illustrated in this paper have been made through restructuring of a UNIX-like operating system.

This approach is more viable when compatibility with the standard version of the system is to be maintained, as in our case. Existing applications, running on the previous standard kernel, keep running on the restructured system. In some cases, however, it is appropriate to modify the applications in order to exploit the features provided by the new mechanisms. For example, from within an end-user application, the new primitives can be used to propagate privileges, or to list the contents of ACLs and of HLs. Obviously, the ACL management primitives can be executed only from within privileged programs.

Compatibility is not preserved for applications interacting with ACL-protected files. In these cases, it is up to the application to identify the protection mode of one file and to further interact with this file according to the proper system call.

The sources of the UNIX kernel and access in “maintenance” mode to a UNIX machine are, however, necessary. Hence, we chose to operate on a UNIX-like system, the MINIX operating system whose sources are available on an IBM PC. Due to the lack in MINIX of an adequate software development environment, we initially implemented a protection system prototype on the MS-DOS environment. The enforcement tasks are simulated by the prototype; the enforcement and the mapper are being re-implemented in the MINIX system.

At the system-call level, MINIX is compatible with UNIX Version 7 and has most of the basic UNIX commands. Its internal architecture considerably differs from that of the UNIX kernel. The MINIX kernel does not have the monolithic structure that characterizes UNIX: rather, it is composed of a set of processes communicating via message passing. Separate processes implement the device drivers, the memory manager and the file system manager. The memory manager executes all system calls related to process and memory management; the file system manager executes all system calls related to access operations on files and directories.

For example, a process willing to read a sequence of bytes from a file must sent a read message to the file system manager (see Fig. 9). If the bytes to be read are not available in internal buffers, the system manager sends a message to the disk driver process and waits for an answer. The disk driver accesses the registers of the disk controller to issue a read command of the disk block containing the requested byte sequence and than waits for a message from the controller (interrupts are also represented as messages) to signal the end of the block read operation. The disk controller sends then a message to the file manager that now copies the requested bytes to the user-process area and send a reply message to the same user process.

Fig. 9. READ operation example.


Fig. 10. An EXEC operation check.

The checks performed upon READ operations are shown in Fig. 10, where continuous lines denote message passing operations and dotted lines denote data transfer operations.

The MZZVZ_Y restructuring approach is mainly characterized by the creation of an enforcement process and by the updating of the memory manager and of the file system manager in order to make them interact with the enforcement.

The enforcement process directly implements the new grant, revoke, delegate, abrogate and entity system calls and executes a set of messates related to access checks and to protection specification management. However, it does not implement the ACLs and HLs access; this task is performed by the file system manager that has analogous procedures for file open.

Although the file system manager implements the acl and hist system calls, it does not know about ACLs and HLs contents. When it performs a security-relevant operation on an ACL- protected file it sends a message to the enforcement which executes the operation. The memory manager has correspondingly been modified to send messages to the enforcement to check the exec right on ACL protected files.

Let us consider the check of a program execution operation (Fig. 10): a user process requests the execution by sending a message to the memory manager. The memory manager then sends a message to the file system manager about the “stat” operation that returns some information on a file attributes, including an attribute for the status of the A flag. If the program to be executed is contained in an ACL-protected (flag A on) file, the memory manager sends a message to the enforcement to check the exec right on the program file and the search right on all parent directories. The enforcement performs these checks by accessing the ACLs of the program and of parent directories and then replies to the memory manager. This process proceeds in the execution of the exec call by loading the program to be executed and then replying to the user process.

The tools using the contents of SSL specification libraries are implemented in Prolog; referring to Fig. 5, the Prolog portion comprises the auth, unauth, sslcatalog commands and the SSL compiler, checker and updater tools. The mapper and the enforcement modules are implemented in C.

8. CONCLUDING REMARKS

This paper has described an environment of tools representing an extension to the standard protection mechanisms of UNIX; the aim is to support flexible resource-sharing policies in cooperative work environments. UNIX basic mechanisms have been illustrated; then, the proposed protection system has been described in detail. The protection model and its specification language (SSL-Security Specification Language) have been presented. The model includes a special kind of subject, the authorizer, who is endowed of the administrative privileges necessary to manage portions of a UNIX-based work environment, such as work areas, system files, project resources (data, tools, packages, programs, etc.). The SSL is available at the user-interface level in order to allow the authorizers to specify the protection requirements of the system resources, and also to create/remove dependent authorizers. Authorizers can thus be organized in a hierarchy that reflects, for example, a project organization (project leader, system analysts, programmers, etc.), where project members work on a need-to-know basis.

Then, the paper has described the tools that check the consistency of SSL specifications formulated by the authorizers, that maintain the SSL libraries of each authorizer consistent and updated, that map the SSL statements into low-level structures for run-time access control, and that keep these structures consistent with SSL statements. These structures are ACLs, which have been used in the implementation of several other protection mechanisms, for example, for UNIX extensions made for multilevel mandatory policy enforcement (e.g. those presented in [ 141). Finally, implementation issues have been described.


The work presented does not explicitely address issues such as the compatibility of kernel level functions or with proposed s~ndardizations for ACLs. The focus has been on developing a model for more selective discretional access controls, and on partitioning the ad~nistrative privileges among different authorizers. The objective is to enable run-time specification of protection policies at the end-user level.

Compatibility with UNIX and with its standards is among the goals of further work, which includes experimentations on a real UNIX kernel and in cooperative work environments for software development, such as in engineering information systems, where various design specialists develop various portions of an engineering system, such as a mechanical plant, or a VLSI system. Tools for cooperative development of Info~ation Systems have been studied in [30] and are currently the basis for evaluation of the system described in this paper.

Acknowledgements-The authors are thankful to Barbara Pemici and Fabio Schreiber for their comments, and to the referees for useful suggestions. This work has been partially supported by the Italian Ministry of Education under a 40% grant and by the project “Informatica e Calcolo Parallelo-LRC INFOKIT of the Italian Research Council.

REFERENCES

[I] M. Bach. The Design of the Unix Operating System. Prentice-Hall, New Jersey (1986). [2] S. Bunch. The SETUID feature in UNIX and security. Proc. fOth National Computer Security Conf. Baltimore

(1987). [3] T. A. Dolotta and R. C. Haight. PWB/UNIX-overview and synopsis of facilities. Technical Report Bell Labs

(1977). [“I] D. E. Denning. Cryptography and Data Security. Addison-Wesley, Reading, MA (1982). [5] D. R. Barstow, H. E. Schrobe and E. Sandewall (eds). Znteractjue Programm~g ~v~ro~~ts. McGmw-Hill, New York

(1984i I. Sommerville. Software Engineering, III Edn. Addison-Wesley, Reading, MA (1989). D. D. Clark and D. R. Wilson. A comparison of commercial and military computer security policies. Proc. IEEE Security & Privacy Symp., Oakland (1986). J. A. Larson. Granting and revoking discretionary authority. Information Systems 8(4) (1983). T. Y. Lin. A generalized information flow model of the role of system security othcers. Database Security: Status and Prospects II. North-Holland, Amsterdam (1989). I. Greif and S. Sarin. Data sharing in group work. ACM Trans. Office Inform. Syst. 5(2) (1988). E. J. McCauley and P. J. Drongowski. KSOS-the design of a secure operating system. Proe. AFfPS National Comp. Conf (1979). G. Popek, M. Kamper, C. Kline, A. Stoughton, M. Urban and E. Walton. UCLA Secure UNIX. Proc. AFIPS NationaZ Comp. Conf (1979). Department of Defense Trusted Computer Systems Evaluation Criteria. Department of Defense, National Computer Security Center, Repor DOD 5200. 28-STD (198.5). V. D. Gligor and E. L. Burch et al. On the design and the implementation of secure XENIX workstations. Proc. IEEE Security & Privacy Symp., Oakland (1986). R. Burgess. Standardization in operating systems Proc. In?. Open Systems Conf, Pinner Publ., U.K. (1987). J. E. Dobson. Reliability and security issues in distributed systems. Proc. Int. Open Systems Conf Pinner Publ., U.K. (1987). Security in open systems, a se~rity ~~e~or~, ECMA Report TR37 (1988). J. P. Kruys. Security of open systems. Comput. Secur. 8(2) (1989). IS0 Draft Addendum to IS0 7489 on security architectures. ISO/TC 97/CS Zl/WG 16-l (1984). B. G. Lindsay and P. F. Wilms. A database authorization mechanism supporting individual and group authorization. Distributed Data Sharing (Van de Riet and Litwin, Eds). North-Holland, Amsterdam (1982). J. Press. Secure transfer of identity and privilege attributes in an open system environment. Comput. Secur. lO(2) (1991). J. McLean. The specification and modeling of computer security. IEEE Comput. Jan., 9-16 (1990). H. Harrison and W. Ruzzo. Protection in operating systems. Commun. ACM 19(S) (1976). P. Wood and S. G. Kochan. UNIX System Security, Hyden Press, Indianapolis, IN (1985). National Computer Security Center. Trusted Network interpretation of the trusted computer system evaluation criteria. Report NCSC-TG-005 (1987). Open systems interconnection, management framework, ECMA Rep. TR37 (1986). U. Bussolati, M. G. Fugini and G. Martella. A conceptual framework for security systems: the action-entity model. Proc. IFIP 9th Comput. Conf, Paris (1983). M. G. Fugini and G. Martella. Conceptual modeling of authorization in database systems. J. Syst. Software 7(l) 3-17 (1987). A. S. Tanenbaum. Operating Systems Design and Implementation. Prentice-Hall, Englewood Cliffs, NJ (1987). M. G. Fugini and F. A. Schreiber. Organization of a design dictionary for cooperative design. Coliarra Progetto Finalizzato Informica-LCR Infokit. IMIPOLI Report (1990).

UNIX-based cooperative environments

APPEAR A

533

An Example of Spectfbion of Protection Policies In this appendix, an example of protection ~qu~~rnent specifications in SSL is described, the example reiates to a software

development project carried on in cooperation by a team of analysts and programmers. The project group (named aipha) is composed of a leader (alpha-leader) and of some programmers. The project is

represented by a program written in C language, composed by some modules assigned to programmers. The configuration of the directory containing the project resources is illustrated in Fig. Al. The oldvers directory

contains the files of old versions of the program; the newvers directory contains the new version of the program; the dot directory includes the do~mentat~on; the usr_id3 and usrid directories are private work areas of the programmers.

C-id4 oldvers newvers usr.33

Fig. Al. Directory of project resources.

The project files are initially owned by the usridi authorizer who then grants their a~inis~tion by norn~~a~~ng usrid as project leader with the task of administering the project resources.

The sharing requirements set by usridl for usrid are the following:

--only usrid3, usrid4, usrid5, usridfi users can be alpha programmers; no other users can hold any privileges on alpha resources;

-no users can change the liles of the old program versions.

These requirements are represented by the SSL statements illustrated in Table Al.

The execution by usridl of the command:

AUTH usrid2, alpha /usr/prjalpha

causes the requirements of Table Al to be transferred into the specification environment of usr_id2; the rules that usrid will further state cannot contradict these specifications.

The protection specifications of authorizer usrid are the following:

-the members of the alpha group are, besides usr_idt, the two programmers usrid and usr_id4; --each programmer can change some modules of the alpha program; -programmers have private working directories; they cannot grant any right to users who are not members of the

alpha group; -the alpha leader can read and modify the new version of the alpha program; -the members of the alpha group can add files to the “ne~e~“dire~to~~ only the creator of a file can remove

it from the newvers directory or replace them with more recent one (this condition does not apply to the alpha leader);

-the members of the alpha group can exec the new and old version of the alpha program; -all members of the alpha group can read the project documentation; only the alpha leader can update the

documentation or grant the programmers to do so.

The SSI statements that represent the above requirements are given in Table A2.

Table Al. SSL protection requirements sp&ied by usr_idt

entify “awk -F: {print $1) /etcJ~~w~ hasnante allows; entity {usr_id3, usr_id4, usrid5, usr_id6f hasname poss_alpha_progrms; eniirv usr id2 hasname alohaaleader: en& all_& - poss_aldha_prog&s - alpha-leader humme not-alphamembs; cmrir~~ “find /usr/p~alph~ -type I - print” humme alphtiles; entity “fine /usr/p@lpha -type d - print” hnsmme alphadirs;

not_alph~membs canmt read, write, exec alphafi~s; not_alpha_membs cannot search, read aiphadirs; not_alpha_membs cawwr add-entry, delete-entry aipha_dirs;

entity “Is /~r/p~alpha/~ldv~s” !EWZGJW old_aIpha_vers;

alphaleader, poss_atpha_progrms cnnnat write old_alphavers;


Table A2. SSL protection requirements set by authorizer us-id2

entity “awk -F: ‘{print $1)’ /etc/passwd” hasname all_usrs; entity {usr_id3, usrid4) hasname alpha_progr; entity usrid hamme alpha-leader; entity alphaprogr + alphaleader hasnmd alpha-team; entity alLusrs - alpha-team humme notalphamembs;

action {read, write, exec) hasname update; action {read, search} hasname see;

entity “fine /usr/prjalpha -type d -print” hasname alpha_dirs;

alpha-team CM see alpha_dirs;

entity “1s /usr/prjalpha/oldvers/*.c” hasname alphamodules; entity {/usr/prjalpha/oldvers/modI.c, /usr/prjalpha/oldvers/mod2.c} hasname usr3_alphamodules; entity alphamodules -usr3_alpha_modules hastame usrrl_alphamodules;

usr_idf can read usrf_alpha_modules; usr_id4 can read usr4_alpha_modules;

entity “Is -R /usr/prjalpha/usr_id3” hasname usr3_alpha_files owner usrid3; entity “1s -R /usr/prjalpha/usrid4” hasname usr4_alpha_tlles owner usrid4; entity “Is /usr/prjalpha/newver” harname alphanewvers;

not_alphamembs cannot update usrLalpha_liles, usr4_alpha_files; alpha-leader C(IR update alpha_newvers; alpha-team can add-entry /usr/prjalpha/newvers; alpha-leader can delete-entry /usr/prjalpha/newvers; alpha-pro@ can delete-entry /usr/prjalpha/newvers if user last access (create) on $filfile = Suser

entity {/usr/pjalpha/oldvers/alpha/usr/pjalpha/newvers/alpha) hamame alpha-bin;

alpha-team enn exec alpha-bin;

entity “1s /usr/prjalpha/doc” hasname alpha_dcc;

alpha-team can read alpha_doe; alphaleader can write alpha_dot; alpha-leader can grant alpha_progr write alpha_dot;

APPENDIX B

An Example of Consistency Checking

In this appendix, some examples of inconsistencies in SSL specifications illustrated.

which are detected by the system are

The specifications of authorizer A 1 are the following:

(1) entity “awk -F: ‘{print $1)’ /etc/passwd” hasname allusrs; (2) entity all-usrs - {usrid2, usrid3, usrid4) hasname notgammamemb; (3) entity “find /usr/prjgamma -type r -print” hasname gammafiles; (4) not_gammamemb cannot read, write gammafiles; (5) entity “1s /usr/prjgamma/man” hasname gamma-man’ (6) usrid cannot grant usrid3, usrid write gammaman;

The specifications of the dependent authorizer A 11 = (usrid2, gamma) are the following:

(7) entity “awk -F: ‘{print $1)’ /etc/passwd” hasname allusrs; (8) entity “1s /usr/prjgamma/man” hasname gammaman owner usrid2; (9) all usrs can read gammaman; (10) usrid can write gammaman; (11) entity { /usr/prjalpha/man/tutorial} hasname tutorial owner usrid3;

The relationships among the entities defined above are illustrated in the entity graph of Fig. Bl(a, b). In this graph, the # numbers denote internal ids assigned by the protection system to entities; the SSL notgammamemb entity has been split into entities # 2 and # 3; system-defined entities # 4 and # 5 represent users usrid and usrid3, respectively.

Figure B2 illustrates a portion of the static graph corresponding to the given specifications. Through the graph, a partial conflict between statement 4 and a statement derived from statement 9 is detected: the conflict is restricted to the users’ members of entity notgammamemb. Rules 4 and 9 produce several inconsistencies on the static graph caused by their derived statements. Authorizer A 11 is returned with statements 4 and 9, and with the explanation of the causes of the conflict.

A portion of the dynamic graph corresponding to the SSL statements is shown in Fig. B3. An inconsistency between statement 10, represented on the static graph, and statement 6, represented on the dynamic graph, is detected.

The specifications also contain an illegal ownership on entity in statement 8 due to statement 6: usrid cannot grant to himself the right to write onto the files belonging to the /usr/prjgamma/man directory; this right would be automatically acquired with the ownership of the files contained in the /usr/prjgamma/man directory.

Multiple ownership exists on the /usr/prjgamma/man/tutorial tile for usrid and usrid due to statements 8 and 11: /usr/prjgamma/man/tutorial is contained in the /usr/prjgamma/man directory and is therefore a member of the entity specified in statement 8.


#7

119

c ’ Y- tiles (At) man (Al) /

Fig. Bl

Fig. B2

read

- Fie. B3

an authorization mechanism for unix-based cooperative environments

Documents