Binary file handouts/ho04.pdf has changed

--- a/handouts/ho04.tex	Sat Oct 18 02:17:51 2014 +0100
+++ b/handouts/ho04.tex	Sat Oct 18 23:07:50 2014 +0100
@@ -1,25 +1,99 @@
 \documentclass{article}
 \usepackage{../style}
 \usepackage{../langs}
+
 \usetikzlibrary{patterns,decorations.pathreplacing}
 
 \begin{document}
 
-\section*{Handout 4 (Unix-Style Access Control)}
+\section*{Handout 4 (Access Control)}
 
 Access control is essentially about deciding whether to grant
-access to a resource or deny it. This sounds easy. Right? Well
-it turns out that things are not as simple as seem at first.
-Let us study as a case how access is organised in Unix-like
-systems (Windows systems have generally similar access
-control, although the details might be quite different).
- 
+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 or ports, access control is organised
-around 11 Bits that specify how a file can be accessed. There
-are three modes for access \textbf{r}ead, \textbf{w}rite and
-e\textbf{x}ecute. Moreover there are .... owner, group and
-everybody else.
+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 87 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.
+
+\subsubsection*{Secrecy and Integrity}
 
 
 

Binary file hws/hw04.pdf has changed

--- a/hws/hw04.tex	Sat Oct 18 02:17:51 2014 +0100
+++ b/hws/hw04.tex	Sat Oct 18 23:07:50 2014 +0100
@@ -27,10 +27,8 @@
 \item What does it mean that the program \texttt{passwd} has the
   \texttt{setuid} bit set? Why is this necessary?
 
-
-\item In the context of which information flow should be protected, explain briefly the 
-differences between the {\it read rule} of the Bell-LaPadula access
-policy and the Biba access policy. Do the same for the {\it write rule}.
+\item With which permissions does the program \texttt{login}
+normally have and why is this needed?
 
 \item A Unix directory might look as follows:
 
@@ -70,6 +68,9 @@
 \end{tabular}
 \end{center}
 
+\item In the context of which information flow should be protected, explain briefly the 
+differences between the {\it read rule} of the Bell-LaPadula access
+policy and the Biba access policy. Do the same for the {\it write rule}.
 
 \end{enumerate}