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.

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:

● 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.

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:

● 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.

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:
 ● R -- read
● W -- write
● X -- execute
● D -- delete
● P -- modify the ACL
● O -- make current account the new owner ("take ownership")

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:

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

NT access control is richer than UNIX, but not fundamentally different.