\documentclass{article}
\usepackage{../style}
\usepackage{../langs}

\usetikzlibrary{patterns,decorations.pathreplacing}

\begin{document}

\section*{Handout 4 (Access Control)}

Access control is essentially about deciding whether to grant
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}

Following the Unix-philosophy that everything is considered as
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: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite
and e\underline{\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. This
relatively fine granularity seems to cover many useful
scenarios of access control. 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 \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 and
links. 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. Links to files never depend
on the permission of the link, but the file they are pointing
to.

While the above might sound already 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, which only
root should be allowed to. 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 90 programs with the setuid
attribute set on my bog-standard Mac OSX system (including the
program \pcode{/usr/bin/login} for example). The problem is
that if there is a security problem with only one of them, be
it a buffer overflow for example, then malicious users 
can gain root access (and for outside attackers it is much
easier to take over a system). Unfortunately it is rather easy 
to make errors since the handling of elevating and dropping 
access rights in such programs rests entirely with the 
programmer.

The fundamental idea behind the setuid attribute is that a
file with this attribute will be able to run not with the
callers access rights, but with the rights of the owner of the
file. So \pcode{/usr/bin/login} will always be running with
root access rights, no matter who invokes this program. The
problem is that this entails a rather complicated semantics of
what the identity of a process (that runs the program) is. One
would hope there is only one such ID, but in fact Unix
distinguishes three(!):

\begin{itemize}
\item \emph{real identity}\\ 
This is the ID of the user who creates 
the process; can only be changed to something else by root. 
\item \emph{effective identity}\\ 
This is the ID that is used to 
grant or deny access to a resource; can be changed to either
the real identity or saved identity by users, can be changed 
to anything by root.
\item \emph{saved identity}\\
If the setuid bit set in a file then the process is started
with the real identity of the user who started the program,
and the identity of the owner of the program as effective and
saved identity. If the setuid bit is not set, then the
saved identity will be the real identity. 
\end{itemize}

\noindent As an example consider again the \pcode{passwd}
program. When started by, say the user \pcode{foo}, it has at
the beginning the identities:

\begin{itemize}
\item \emph{real identity}: \pcode{foo}\\
\emph{effective identity}: \pcode{foo}\\ 
\emph{saved identity}: \pcode{root}
\end{itemize}

\noindent It is then allowed to change the effective
identity to the saved identity to have

\begin{itemize}
\item \emph{real identity}: \pcode{foo}\\
\emph{effective identity}: \pcode{root}\\ 
\emph{saved identity}: \pcode{root}
\end{itemize}

\noindent It can now read and write the file
\pcode{/etc/passwd}. After finishing the job it is supposed to
drop the effective identity back to \pcode{foo}. This is the
responsibility of the programmers who wrote \pcode{passwd}.
Notice that the effective identity is not automatically
elevated to \pcode{root}, but the program itself must make
this change. After it has done the work, the effective
identity should go back to the real identity.


Despite these complicated semantics, Unix-style access control
is of no use in a number of situations. For example it cannot
be used to exclude some subset of people, but otherwise have
files readable by everybody else (say you want to restrict
access to a file such that your office mates cannot access 
a file). You could try setting the group of the file to this
subset and then restrict access accordingly. But this does not
help, because users can drop membership in groups. 

\subsubsection*{Secrecy and Integrity}



\subsubsection*{Further Information}

If you want to know more about the intricacies of the
``simple'' Unix access control system you might find the
relatively readable paper about ``Setuid Demystified'' 
useful.

\begin{center}\small
\url{http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf}
\end{center}


\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: