--- a/handouts/ho04.tex Sun Oct 19 00:41:51 2014 +0100
+++ b/handouts/ho04.tex Sun Oct 19 14:00:28 2014 +0100
@@ -27,8 +27,9 @@
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:
+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}}
@@ -46,19 +47,21 @@
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.
+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 moderately complicated, the real
-complications with Unix-style file permissions involve the
-setuid and setgid attributes. For example the file
+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
@@ -85,19 +88,69 @@
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.
+\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 main rule for files that have the setuid attribute set is
+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.
+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}
@@ -111,7 +164,7 @@
useful.
\begin{center}\small
-\url{http://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/downloads/setuid.pdf}
+\url{http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf}
\end{center}