--- a/handouts/ho04.tex Sun Oct 19 16:02:36 2014 +0100
+++ b/handouts/ho04.tex Sun Oct 19 16:44:31 2014 +0100
@@ -24,12 +24,13 @@
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:
+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}}
@@ -39,12 +40,12 @@
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
+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
@@ -74,9 +75,10 @@
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
+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
@@ -91,18 +93,22 @@
\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.
+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 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
+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(!):
@@ -123,9 +129,9 @@
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:
+\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}\\
@@ -143,14 +149,23 @@
\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.
+\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.
-
-Cannot be used to exclude some people
+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}