\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

{\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}

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

\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

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}

\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

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