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:
Today we will discuss UNIX and NT and see how they handle 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:
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:
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: