diff -r e272713e34ff -r 9bc912fcedb6 handouts/ho04.tex
--- a/handouts/ho04.tex	Tue Oct 21 12:42:19 2014 +0100
+++ b/handouts/ho04.tex	Wed Oct 22 23:38:02 2014 +0100
@@ -51,14 +51,15 @@
 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.
+access any file inside it. If the write attribute is
+\emph{not} set, then one can change existing files (provide
+they are changeable), but one cannot create new files. If the
+read attribute is \emph{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. Otherwise one could easily change access
+rights to files.
 
 While the above might sound already moderately complicated,
 the real complications with Unix-style file permissions
@@ -95,12 +96,12 @@
 attribute set on my bog-standard Mac OSX system (including the
 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.
+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
+cause a security problem since the handling of elevating and
+dropping access rights in such programs rests entirely with
+the programmer.
 
 The fundamental idea behind the setuid attribute is that a
 file will be able to run not with the callers access rights,
@@ -158,18 +159,82 @@
 identity should go back to the real identity.
 
 
-Despite these complicated semantics, Unix-style access control
+Despite this 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. 
+help, because users can drop membership in groups. If one
+needs such fine-grained control over who can access a file,
+one needs more powerful \emph{mandatory access controls}
+as described next.
+
 
 \subsubsection*{Secrecy and Integrity}
 
+Often you need to keep information secret within a system or
+organisation, or secret to the ``outside world''. An example
+would be to keep information secret such that insiders cannot
+leak information to competitors. A very good instance of such
+an access control system is the secrecy levels used in the
+military. There you distinguish four secrecy levels:
 
+\begin{itemize}
+\item top secret
+\item secret
+\item confidential
+\item unclassified
+\end{itemize}
+
+The idea is that the secrets classified as top-secret are most
+closely guarded and only accessible to people who have a
+special clearance. The unclassified category is the lowest
+level not needing any clearance. While the idea behind these
+security levels is quite straightforward, there are some
+interesting implications for when you want to realise such a
+system. To begin the access control needs to be
+\emph{mandatory} as opposed to \emph{discretionary}. With
+discretionary access control, the users can decide how to
+restrict or grant access to resources. With mandatory access
+control, the access to resources is enforced ``system-wide''
+and cannot be controlled by the user. There are also some
+interesting rules for reading and writing an object that 
+need to be enforced: 
+
+
+\begin{itemize}
+\item {\bf Read Rule}: a principal $P$ can read an object $O$
+provided $P$'s security level is at least as high as $O$'s
+
+\item {\bf Write Rule}: a principal $P$ can write an object $O$
+provided $O$'s security level is at least as high as $P$'s 
+\end{itemize} 
+
+\noindent The first rule says that a principal with secret
+clearance can read secret documents or lower, but not
+documents classified top-secret. The second rule for writing
+needs to be the other way around: someone with secret
+clearance can write secret or top-secret documents---no
+information is leaked. In contrast it cannot write
+confidential documents, because then information can be leaked
+to lower levels. These rules about enforcing secrecy with
+mult-level clearances is often called \emph{Bell/LaPudela}
+model, named after two people who studied such systems.
+
+A problem with this access control system is when two people
+want to talk to each other but having different security
+clearances, say secret and confidential. In these situations,
+the people with the higher clearance have to lower their
+security level and are not allowed to take any document
+from the higher level with them (otherwise again information
+could be leaked). In actual systems this might mean that
+people need to log out and log into the system again---this
+time with credentials for the lower level.
+
+While secrecy is one property you often want to enforce,
+integrity is another. This property ensures that no
 
 \subsubsection*{Further Information}