Access Control in UNIX and Windows NT

Lecturer: Professor Fred B. Schneider

Lecture notes by Lynette I. Millett


We have been discussing access control policies and have been concerned with defining what accesses subjects can make to objects. We model this behavior with a protection matrix and commands. In the last lecture, we pointed out that there are at least two ways to implement the matrix:

We noted that there are two generic ways to implement ACLs. One is to employ a mechanism for name interpretation, to put a layer between the names a subject utters and what those names mean. Another is operation interpretation, to put the protection mechanism into the execution of an operation.

Today we will discuss UNIX and NT and see how they handle access control.

UNIX -- Access Control

UNIX uses access control lists. A user logs into UNIX and has a right to start processes that make requests. A process is "bigger" than a subject, many domains may correspond to a single process. Each process has an identity(uid). This uid is obtained from the file that stores user passwords: /etc/passwd. An entry in /etc/passwd may look like:

Every process inherits its uid based on which user starts the process. Every process also has an effective uid, also a number, which may be different from the uid.

Finally, each UNIX process is a member of some groups. In the original UNIX every user was a member of one group. Currently, users can be members of more than one group. Group information can be gotten from /etc/passwd or from a file /etc/groups. System administrators control the latter file. An entry in /etc/groups may look like:

When a process is created, associated with it is the list of all the groups it is in.

Recall that groups are a way to shorten access control lists. They are useful in other ways as well.

All of the above implements a form of authentication, knowing the identity of the subject running commands. Objects in UNIX are files. UNIX attempts to make everything look like a file. (E.g., one can think of "writing" to a process as equivalent to sending a message, etc.) Because of this, we will only worry about files, recognizing that just about every resource can be cast as a file.

Here is a high-level overview of the UNIX file system. A directory is a list of pairs: (filename, i-node number). Running the command 'ls' will produce a list of filenames from this list of pairs for the current working directory. An i-node contains a lot of information, including:

Nine of the 12 mode bits are used to encode access rights. These access bits can be thought of as the protection matrix entry. They are divided into three groups of three:

The first triplet (u) is for the user, the second (g) for the group and the third (o) for anyone else. If a particular bit is on, then the named set of processes have the corresponding access privileges (r:read, w:write, x:execute).

There are some subtleties however. In order to access a file, it is necessary to utter that object's name. Names are always relative to some directory, for example: ~fbs/text/cs513/www/L07.html. Directories are just files themselves, but in the case of directories:

Thus, for example, the 'x' bit allows a user to make the directory under consideration the current working directory and it needs to be on to read files in the current working directory. So a file can be made inaccessible by turning off the 'x' bit for the directory in which the file resides.

Does 'x' without 'r' access make sense? Yes! This is a directory whose files' names cannot be learned, but whose files are accessible if you happen to know their names. This is actually useful.

Does 'r' without 'x' access make sense? This is a directory whose files' names can be learned, but whose files cannot be accessed. It is not very useful.

How do these access bits get set? In UNIX there are number of rules to define how the bits are set initially and how they can be changed. We will discuss how to change them. There is a command 'chmod' that changes the mode bits. What objects can chmod access? Only the uid that is the owner of a file can execute chmod for that file (except for root's uid, of course). There is also a command to change the owner of a file, but that has been removed from more recent systems.

What about the final three of the 12 mode bits? The mechanism discussed so far does not support domain changes. There is a single domain, the user id, and once a process is running it is (abstractly) in that row of the protection matrix. Imagine a situation where we want files to be viewable only from within a particular program. This is not possible in the current framework. But, the additional mode bits allow this. We will only mention two of the three bits. They are: suid (set user id) and sgid (set group id). A file with the suid bit on does not run with the uid of the process making the call, but rather with an effective uid that is the owner of the file. This enables us to change from executing as one subject to executing as another subject. The sgid bit works on the same principle, but for groups.

These additional mode bits are used when there are programs that access lots of objects but in a controlled way (e.g. root privileges). It is useful to have programs that are setuid for a user, and thus do less damage than a user running the program with full root privileges. We do not have the notion of a template, as we discussed previously, so this UNIX mechanism is less powerful. We do not realize the principle of least privilege.

There is a UNIX that uses a notion of an additional access control list, and not just mode bits to handle access control. In this case, each file has mode bits as we have been discussing and also extended permissions. The extended permissions provide exceptions to the mode bits as follows:

With extended permissions it's possible to force a user to enter a particular group before being allowed access to a file.

Windows NT -- Access Control

Windows NT supports multiple file systems, but the protection issues we will consider are only associated with one: NTFS. In NT there is the notion of an item, which can be a file or a directory. Each item has an owner. An owner is usually the thing that created the item. It can change the access control list, allow other accounts to change the access control list and allow other accounts to become owner. Entries in the ACL are individuals and groups. Note that NT was designed for groups of machines on a network, thus, a distinction is made between local groups (defined on a particular workstation) and global groups (domain wide). A single name can therefore mean multiple things.

NTFS is structured so that a file is a set of properties, the contents of the file being just one of those properties. An ACL is a property of an item. The ACL itself is a list of entries: (user or group, permissions). NTFS permissions are closer to extended permissions in UNIX than to the 9 mode bits. The permission offer a rich set of possibilities:

The owner is allowed to change the ACL. A user with permission P can also change the ACL. A user with permission O can take ownership. There is also a packaging of privileges known as permissions sets: NT access control is richer than UNIX, but not fundamentally different.