\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: \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 95 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.

The main rule for files that have the setuid attribute set is
that when running such files they will run not with the
callers access rights, but with the owner of the files rights.
So \pcode{/usr/bin/login} will always be running with root
access rights, no matter who invokes this program.

\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.umd.edu/~jkatz/TEACHING/comp_sec_F04/downloads/setuid.pdf}
\end{center}


\end{document}

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