\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. This relatively fine granularity seems to+
−
cover many cases 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 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 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. 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}). 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 (or outside+
−
attackers) can gain root access.+
−
+
−
The idea 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. 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 \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}. Note 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 goes back to the real identity.+
−
+
−
+
−
+
−
Cannot be used to exclude some people+
−
+
−
\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: +
−