Access Control in UNIX and Windows NT

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:

• access control lists (ACLs)-- the column for each object stored as a list associated with that object.
• capabilities -- the row for each subject stored as a list associated with that subject.

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

UNIX -- Access Control

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:

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:

• where the file is stored -- necessary since the directory entry is used to access the file,
• the length of the file -- necessary to avoid reading past the end of the file,
• the last time the file was read,
• the last time the file was written,
• the last time the i-node was read,
• the last time the i-node was written,
• the owner -- a uid, generally the uid of the process that created the file,
• a group -- gid of the process that created the file is a member of,
• 12 mode bits to encode protection privileges -- equivalent to encoding a set of access rights.

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:

• The "r" (read) bit controls the ability to read the list of files in a directory. If "r" is set, you can use "ls" to look at the directory.

• The "x" (search) bit controls the ability to use that directory to construct a valid pathname. If the "x" bit is set, you can look at a file contained in the directory.

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:

• Specify: for example, "r-- u:harry" means that user harry has read only access.
• Deny: for example "-w- g:acsu" means remove write access from the group acsu.
• Permit: for example "rw- u:bill, g:swe" means give read and write access to bill if bill is also a member of the group swe. The comma is conjunction.

Windows NT -- Access Control

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:

• R -- read
• W -- write
• X -- execute
• D -- delete
• P -- modify the ACL
• O -- make current account the new owner ("take ownership")

• no access
• read -- RX
• change -- RWXO
• full control -- RWXDPO