Sebery J.Cryptography.An introduction to computer security.1989

17.4.2 Multics

This section is based on the description of Multics given in [396]. The Multics system is an operating system whose access control shows many similarities with the Bell-LaPadula model. In fact, the Bell-LaPadula model evolved from the Multics access control mechanism. Multics is a fulledged operating system and its description goes beyond the the scope of the book. We give a brief account of the Multics access control.

All resources are organized in hierarchy of concentric rings of protection. The innermost ring is D0. The outermost ring is DN . A single ring Di constitutes a protection domain. D0 is the most privileged and DN is the least privileged domain. Multics treats all resources uniformly as segments ( les) arranged into a hierarchical le system. Executable les are subjects (or procedures). Passive objects are data les (data segments). The relation between the protection rings and the hierarchy of les is de ned by the security policy. Assume that a process s 2 Di invokes a process s0 2 Dj. The general rule for access control is:

{If j i, the access is permitted { a more privileged process s can always call a less privileged one.

{If j < i, the access is either denied or controlled, i.e. it is possible via so-called entry points or gates.

The gate notion is a generalization of system calls. Any attempt by s 2 Di to invoke s0 2 Dj ; when i > j, will be treated as an error and will generate a trap into s0. The process s0 may deliver a service to s only if the process s has suitable permissions.

Multics de nes two possible implementations of access control using:

1.access brackets, and

2.call brackets.

Instead of a single ring, a resource is assigned a band of rings (k; `) where k `. The pair (k; `) constitutes the access brackets of the resource.

Assume that a process s 2 Di wishes to access a data le f with its access brackets (k; `). The access control rules are:

{If i k, then the access is granted.

{If k + 1 i `, then reading/execution access is granted while writing/append access is denied.

582 17 ACCESS CONTROL

{ If i > `, the access is denied.

If the process s 2 Di wishes to access a process s0 with its access brackets (k; `), then the access control rules are slightly di erent and are:

{If i < k, then the access is granted and a ring-crossing fault is induced.

{If k i `, then the access is granted.

{If i > `, the access is denied.

Note that in the above access control, if i > `, all access is denied. To relax this, Multics introduced call brackets. A process is assigned three integers (k; `; m) where (k; `) is access brackets and m is call bracket (or range). Call brackets are de ned for subjects (procedure segments) only. The access rules are as above with the following addition:

{If ` < i m, then access is granted via speci c entry points (gates).

{If i > m, the access is denied.

The Multics project was aiming to design a secure and eÆcient multiuser operating system. The access control was an integral part of the overall security. The ring structure of protection domains although conceptually elegant, puts restrictions on access control. Any subject in an inner ring Di can access any object from all outer rings Dj for i < j no matter whether the subject needs the object or not. In other words, the need-to-know principle is not supported in Multics.

17.4.3 UNIX

The UNIX access control evolved from Multics and some of Multics features are still present in UNIX. One of them is the tree structure of the le system. There are two basic types of elements in the le system: directories and les. Files can be further classi ed into data les and executable les. The tree structure is relaxed by the presence of the so-called links which are pointers to les in some other subdirectories. The collection of permissions supported by UNIX are write (w), read (r) and execute (x).

Users are assigned their home directories. It is the user responsibility to build and maintain their own subtree rooted in the user home directory. This responsibility includes permission assignment to all les owned by the user. Subjects in UNIX are de ned into three broad categories:

Fig. 17.1. Listing of les in UNIX

1.owner,

2.group the owner is in,

3.universe (all other users).

Listing of a typical subdirectory is given in Figure 17.1. To descibe access permissions to a le or directory, it is enough to give collection of triplets of the form rwx to the owner, the group and the universe. So each le may have up to 9 permissions. For instance, the form le can be read and written by the owner (this is indicated by rw-), can be read by the group (see the next triplet r--), and is not accessible to the universe (the last triplet ---). By the way, the rst character in the listing speci es the type of le (data le indicated by - or directory denoted by d). To grant or deny access to a le, the UNIX system checks whether the user who asks for access

{Is the owner of the le. If she is, then UNIX considers the owner permissions.

{Belongs to the group. If she does, then UNIX compares the requested access with the group permissions.

{Otherwise, the UNIX compares the requested access with the universe permissions.

UNIX allows a single user to be a member of di erent groups. In System V, the command newgrp allows users to switch between groups. The owner of a le is always able to set permissions to the le. The command chmod can be used for this purpose. Also the ownership of a le can be transferred by the current owner to other user by using the chown command.

While creating new les (by copying, editing or running a process which creates new les), UNIX assigns permissions according to default permissions. They can be controlled by the umask command. To modify the default to the requested permission pattern, it is enough to call the command umask abc where a,b,c are integers from 0 to 7. So if you execute umask 037, then

By default, any new le created by the owner gets full range of permissions speci ed by the application. If the application is an editor, this is typically rw-. for executable les, the default is rwx. The group can read the new le, i.e. their permissions are r--. The universe gets no access or ---.

Unlike data les, directories play a di erent role. They are used to partition the le system into subtrees and keep information about them (who can use them and where they are stored on the disks). Consequently, a directory is a list of lenames together with addresses to their inodes where the information about their owners, permissions and location on the disks is kept. Clearly, access permissions for directories are de ned di erently and [167]

{r-- means that the contents of directory can be listed,

{-wx means that les in the directory are allowed to be renamed or deleted,

{--x means that les in the directory are permitted to be executed.

The UNIX access control uses owners, groups and the universe to de ne access permissions. This resembles a three ring structure. The owner is in the center, the group creates the rst ring and the universe sits in the outer ring. The current list of permissions to an object ( le) may be assigned independently by the owner. Some obvious restrictions in access control is a weak granulity of the group and the universe. If the owner of a le wishes to allow sharing it with another user, then the owner must allow the same access to the group the user is in. UNIX also de nes the all-powerful superuser (root) who is typically the administrator responsible for maintainance and smooth operation of the system. More details about UNIX and its security can be found in [167].

17.4.4 Capabilities

Consider an access matrix from Section 17.2.1 with rows and columns indexed by subjects and objects, respectively. Note that the access matrix normally is sparse as most objects are not accessible to many subject. It is, therefore, reasonable to split the matrix into smaller and more manageable units. One of the possibilities is to assign to each subject the corresponding row of the

Server Port Object Permissions Check

Fig. 17.2. The Amoeba capability

access matrix. For a given subject (or protection domain), the capability list speci es the collection of accessible objects together with permissions to them. A capability is an object representation usually in the form of its name or identi er together with permissions.

It is said that a subject can access an object if the subject possesses an object capability. Capabilities are protected objects themselves and they must be protected against modi cation by users. There are three basic solutions which have been used to protect capabilities [502]:

{Tagged architecture { capabilities are stored in memory with a tag bit switched on indicating that it can be modi ed by the kernel only.

{Isolation from users { capabilities are kept by the operating system so user can refer to them only.

{Cryptographic techniques { users are allowed to hold capabilities but any modi cation will be detected by the operating system.

A capability-based access control has an obvious advantage. It is easy to decide whether to grant or deny the access as subjects must present valid capabilities. Note that it is the subject responsibility to store and maintain capabilities. Operating system generates and veri es capabilities. For a given object, however, it is diÆcult to

{determine which subjects are allowed to access it and what permissions they have to the object,

{revoke permissions to the object.

The above-mentioned diÆculties relate to the fact that capabilities are scattered around di erent subjects.

Let us illustrate how capabilities can be used for access control. The Amoeba distributed operating system was designed at the Vrije University [362, 501]. The Amoeba access control is capability based. The format of capabilities in Amoeba is shown in Figure 17.2. The rst two elds uniquely identify an object. They, in fact, constitute the object name. The last two are used for access control. The permission eld is a binary string (8-bit long), that speci es the

586 17 ACCESS CONTROL

collection of operations allowed to be performed by the capability holder. The check eld (48-bit long) is used for validation of capabilities. The integrity of a capability is enforced cryptographically.

The following operations on capabilities are de ned in Amoeba:

{Creation of an owner capability { This operation is performed when a new object is created. The owner of the object asks the server (who is a part of OS) to issue an owner capability. In response, the server creates the capability with all permission bits turned on and with a random string in the check eld. The information about the capability is also stored by the server in the le tables for further references. In e ect, the owner holds a valid capability and the server has registered the new capability.

{Veri cation of an owner capability { The holder of a capability presents it to the server, which retrieves its registration information. Next the server compares the registration information with this provided by the capability.

{Creation of a derivative capability { Assume that a user holds a valid owner capability and asks the server to create a restricted capability with the permission bit pattern p. First, the server veri es whether the capability held by the user is valid. If it is, the server takes the random check number x from the owner capability, adds it exclusive-or to p and the result is input to a

one-way function f(). The result is the new check string which is returned to

the user. In other words, the new check string x0 = f (x p) and the matching permission pattern is p.

{Veri cation of a derivative capability { Given a derivative capability with the permissions p and the check value x~. A holder of a derivative capability asks the server for veri cation. The server retrieves the information about the owner capability, takes the check value of the owner capability x adds to

it the permissions p from the derivative capability and calculates the valid

check string x0 = f(x p). If the value x0 is equal to x~, the capability is considered valid.

Note that capabilities resemble tokens. The access is granted when a user is able to present to the server a valid capability. The resitance of capabilities against forgery rests on the diÆculty of reversing the one-way function and the length of the check eld.

The Amoeba access control has the following interesting features:

{Garbage collection { when an object is no longer accessible because all capabilities have been lost. This is done by removing all objects which have not been used for the last garbage collection cycles.

{Revocation of access { the holder of a capability can always propagate copies of the capability. To revoke the access, the owner can ask the server to invalidate all capabilities by changing the check number stored in the le table.

{Controlled propagation of capabilities { a holder of a derivative capability can ask the server to create a capability with more resticted permissions.

There are many operating systems whose access control applies capabilities. Hydra [540] allows users to de ne their own (access) operations using the basic ones provided by the system. Those new permissions are called auxiliary rights. The CAP system [372] uses two types of capabilities: data and software. Data capabilities are standard permissions provided by the system (read, write, execute). Software capabilities, on other hand, allow users to de ne their own access operations.

17.4.5 Access Control Lists

An alternative to capabilities is the concept of access control lists (ACL). Instead of slicing the access matrix by rows, the matrix is divided by columns. So every object is asssigned its ACL which speci es who (which subject or protection domain) and how (access permissions) can use the object. This idea have been adopted in UNIX (Section 17.4.3).

Consider how ACLs are implemented in the DCE distributed operating system. DCE which stands for Distributed Computing Environment was a project initiated by a group led by IBM, DEC and Hewlett Packard. The goal of the project was to develop a version of UNIX for distributed environment [435, 501].

The DCE operating system follows the client/server paradigm. Users are identi ed by their client processes and services by server processes. All computing resources are clustered together into cells. A cell typically covers resources of a department or division so can be identi ed by resources hooked to a single LAN.

Unlike in capability-oriented access control where the fact of possessing a valid capability is enough to grant the access, ACL-oriented access control requires identi cation of users (subjects) who issue access requests. The identi -

588 17 ACCESS CONTROL

sample data

/: : :/C=AU/O=UOW/OU=ITACS

user:josef:rwxcidt

user:jennie:rwxidt

user:thomas:rwxidt

group:staff:rxt

other:t

foreign user:john@/: : :/cs.qut.edu.au:rwxt

foreign group:staff@/: : :/cs.qut.edu.au:rt

Fig. 17.3. An example of ACL in the DCE system

cation used in DCE are based on the Kerberos system. For identi cation purposes, users are given privilege attribute certi cates (PAC), which are simply cryptograms of the message which includes: the user identity, group and organization memberships. ACLs are protected entities kept by ACL managers. ACL managers are privileged library routines present in every server.

Objects are divided into two categories: simple objects, such as les, and complex objects called containers, such as directories. The collection of permissions is an extension of those present in UNIX and includes

{read (r),

{write (w),

{execute (x),

{change-ACL (c),

{container-insert (i),

{container-delete (d), and

{test (t).

The only permission that is not self explanatory is test. The test permission allows to check whether or not the value stored in the protected object is equal to some value without revealing the protected value. For instance, a user who has t permission to the password le, can verify whether the password in hand is equal to the password stored in the le without getting any additional information about the stored password. An example of ACL is given in Figure 17.3. Therst row indicates the type of the object. The second row identi es the default cell. Next the table speci es permissions of three users and of the group staff existing in the cell. All other local users can test the object (row 7). Finally,

there are two foreign subjects (user and group) whose permissions are given in the last two rows.

Assume that a client (user) wishes to access a le. First the client contacts the suitable server and presents her PAC together with her access request. The server decrypts the PAC, retrieves her identity and memberships and looks up the appropriate ACL. If her name or groups she belongs appear on ACL, the server checks permissions and grants the access if the request is consistent with the permissions. Otherwise, the request is denied.

The owner (creator) of an object typically retains all permissions. The DCE system provides also the ACL editor, which can be called by clients to create new objects and subjects, manipulate the contents of ACLs, etc. Clearly, any call to the ACL editor is scrutinized against the caller's permissions.

Windows NT provides another example of access control based on ACLs. Readers interested in this subject are referred to the book [228].

Let us compare capabilities with ACLs. First consider how the access control is performed.

{Capabilities { access is granted if a valid capability is presented. The identity of the capability holder is not veri ed. The fact that a user holds a valid capability is enough to grant the access. Capabilities, however, have to be protected against modi cation.

{ACLs { access is granted to a user if the name of the user together with suitable permissions appears on the object ACL. Every time users request access, they have to be identi ed by the operating system.

Capabilities seem to be more suitable for distributed environment. The protection mechanism and naming can be merged making the access control moreexible. Capabilities can be easier incorporated into programming languages. On the other hand, ACLs o er better protection as users are always identi ed before allowing the access. It is easier to keep track who has been using what objects.