\section*{Handout 4 (Access Control)}

access to a resource or deny it. Sounds easy. No? Well it

turns out that things are not as simple as they seem at first

glance. Let us first look as a case-study at how access

control is organised in Unix-like systems (Windows systems

have similar access controls, although the details might be

quite different).

\subsubsection*{Unix-Style Access Control}

a file, even memory, ports and so on, access control in Unix

is organised around 11 Bits that specify how a file can be

accessed. These Bits are sometimes called the \emph{permission

attributes} of a file. There are typically three modes for

access: \textbf{r}ead, \textbf{w}rite and e\textbf{x}ecute.

Moreover there are three user groups to which the modes apply:

the owner of the file, the group the file is associated with

and everybody else. A typical example of some files with

permission attributes is as follows:

{\small\lstinputlisting[language={}]{../slides/lst}}

\noindent The leading \pcode{d} in Lines 2 and 6 indicate that

the file is a directory, whereby in the Unix-tradition the

\pcode{.} points to the directory itself. The \pcode{..}

points at the directory ``above'', or parent directory. The

second to fourth letter specify how the owner of the file can

access the file. For example Line 3 states that \pcode{ping}

can read and write the \pcode{manual.txt}, but cannot execute

it. The next three letters specify how the group members of

the file can access the file. In Line 4, for example, all

students can read and write the file \pcode{report.txt}.

Finally the last three letters specify how everybody else can

access a file. This should all be relatively familiar and

straightforward. No?

There are already some special rules for directories. If the

execute attribute of a directory is \emph{not} set, then one

cannot change into the directory and one cannot access any

file inside it. If the write attribute is not set, then one

can change existing files (provide they are changeable), but

one cannot create new files. If the read attribute is not set,

one cannot search inside the directory (\pcode{ls -la} does

not work) but one can access an existing file, provided one

knows its name.

While the above might sound moderately complicated, the real

complications with Unix-style file permissions involve the

setuid and setgid attributes. For example the file

\pcode{microedit} in Line 5 has the setuid attribute set

(indicated by the \pcode{s} in place of the usual \pcode{x}).

The purpose of setuid and setgid is to solve the following

puzzle: The program \pcode{passwd} allows users to change

their passwords. Therefore \pcode{passwd} needs to have write

access to the file \pcode{/etc/passwd}. But this file cannot

be writable for every user, otherwise anyone can set anyone

else's password. So changing securely passwords cannot be

achieved with the simple Unix access rights discussed so far.

While this situation might look like an anomaly, it is in fact

an often occurring problem. For example looking at current

active processes with \pcode{/bin/ps} requires access to

internal data structures of the operating system. In fact any

of the following actions cannot be configured for single

users, but need privileged root access

\begin{itemize}

\item changing system databases (users, groups, routing tables

and so on)

\item opening a network port below 1024

\item interacting with peripheral hardware, such as printers, 

harddisk etc

\item overwriting operating system facilities, like

process scheduling and memory management

\end{itemize}

\noindent This will typically involve quite a lot of

programs on a Unix system. I counted 87 programs with the

setuid attribute set on my bog-standard MacOSX system

(including the program \pcode{/usr/bin/login}).

The problem is that if there is a security problem with

one of them, then malicious users (or outside attackers)

can gain root access.

\subsubsection*{Secrecy and Integrity}