--- a/handouts/ho04.tex Thu Oct 08 18:46:15 2015 +0100
+++ b/handouts/ho04.tex Tue Oct 13 03:45:37 2015 +0100
@@ -3,7 +3,7 @@
\usepackage{../langs}
\begin{document}
-\fnote{\copyright{} Christian Urban, 2014}
+\fnote{\copyright{} Christian Urban, 2014, 2015}
\section*{Handout 4 (Access Control)}
@@ -15,8 +15,109 @@
have similar access controls, although the details might be
quite different). Then we have a look at how secrecy and
integrity can be ensured in a system, and finally have a look
-at shared access control in multi-agent systems.
+at shared access control in multi-agent systems. But before we
+start, let us motivate access control systems by the kind of
+attacks we have seen in the last lecture. \bigskip
+
+\noindent There are two further general approaches for
+countering buffer overflow attacks (and other similar
+attacks). One are Unix-like access controls, which enable a
+particular architecture for network applications, for example
+web-servers. This architecture minimises the attack surface
+that is visible from, for example, the Internet. And if an
+attack occurs the architecture attempts to limit the damage.
+The other approach is to \emph{radically} minimise the attack
+surface by running only the bare essentials on the web-server.
+In this approach, even the operating system is eliminated.
+This approach is called \emph{unikernel}.
+
+A \emph{unikernel} is essentially a single, fixed purpose
+program running on a server. Nothing else is running on the
+server, except potentially many instances of this single
+program are run concurrently with the help of a
+hypervisor.\footnote{Xen is a popular hypervisor; it provides
+the mechanism of several virtual machines on a single
+computer.} This single program implements the functionality
+the server offers (for example serving web-pages). The main
+point is that all the services the operating system normally
+provides (network stack, file system, ssh and so on) are not
+used by default in unikernels. Instead, the single program
+uses libraries (the unikernel) whenever some essential
+functionality is needed. The developer only needs to select a
+minimal set of these libraries in order to implement a server
+for web-pages, for example. In this way, ssh, say, is only
+provided, when it is absolutely necessary.
+
+Unikernels are a rather recent idea for hardening servers. I
+have not seen any production use of this idea, but there are
+plenty of examples from academia. The advantage of unikernels
+is the rather small footprint in terms of memory, booting
+times and so on (no big operating system is needed). This
+allows unikernels to run on low-coast hardware such as
+Raspberry Pis or Cubieboards, where they can replace much more
+expensive hardware for the same purpose. The low booting times
+of unikernels are also an advantage when your server needs to
+scale up to higher user-demands. Then it is often possible to
+just run another instance of the single program, which can be
+started almost instantly without the user seeing any delay
+(unlike if you have to start, say, Windows and then on top of
+that start your network application). One of the most
+well-known examples of a unikernel is MirageOS available from
+\begin{center}
+\url{https://mirage.io}
+\end{center}
+
+\noindent This unikernel is based on the functional
+programming language Ocaml, which provides added security
+(Ocaml does not allow buffer overflow attacks, for example).
+If you want to test the security of MirageOS, the
+developers issued a Bitcoin challenge: if you can break into
+their system, you can get 10 Bitcoins
+
+\begin{center}
+\url{http://ownme.ipredator.se}
+\end{center}
+
+However, sometimes you cannot, or do not want to, get rid of
+the operating system. In such cases it is still a good idea
+to minimise the attack surface. For this it helps if the
+network application can be split into two parts---an
+application and an interface:
+
+\begin{center}
+ \begin{tikzpicture}[scale=1]
+
+ \draw[line width=1mm] (-.3, 0) rectangle (1.5,2);
+ \draw (4.7,1) node {Internet};
+ \draw (-2.7,1.7) node {\footnotesize Application};
+ \draw (0.6,1.7) node {\footnotesize Interface};
+ \draw (0.6,-0.4) node {\footnotesize \begin{tabular}{c}unprivileged\\[-1mm] process\end{tabular}};
+ \draw (-2.7,-0.4) node {\footnotesize \begin{tabular}{c}privileged\\[-1mm] process\end{tabular}};
+
+ \draw[line width=1mm] (-1.8, 0) rectangle (-3.6,2);
+
+ \draw[white] (1.7,1) node (X) {};
+ \draw[white] (3.7,1) node (Y) {};
+ \draw[<->, line width = 2mm] (X) -- (Y);
+
+ \draw[<->, line width = 1mm] (-0.6,1) -- (-1.6,1);
+ \end{tikzpicture}
+\end{center}
+
+\noindent The idea is that all heavy-duty lifting in the
+application (for example database access) is done by a
+privileged process. All user input from the internet is
+received by an \emph{un}privileged process, which is
+restricted to only receive user input from the Internet and
+communicates with the privileged process. This communication,
+however, needs to be sanitised, meaning any unexpected
+user-input needs to be rejected. The idea behind this split is
+that if an attacker can take control of the
+\emph{un}privileged process, then he or she cannot do much
+damage. However, the split into such privileged and
+unprivileged processes requires an operating system that
+supports Unix-style access controls, which look at next.
\subsubsection*{Unix-Style Access Control}
@@ -49,9 +150,8 @@
will only have read-write access permissions, not
read-write-execute.
-This
-relatively fine granularity of owner, group, everybody else
-seems to cover many useful scenarios of access control. A
+This relatively fine granularity of owner, group, everybody
+else seems to cover many useful scenarios of access control. A
typical example of some files with permission attributes is as
follows:
@@ -89,6 +189,7 @@
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
@@ -117,14 +218,14 @@
\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} 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
-cause a security problem since the handling of elevating and
-dropping access rights in such programs rests entirely with
-the programmer.
+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 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,
@@ -220,9 +321,9 @@
Often you need to keep information secret within a system or
organisation, or secret from the ``outside world''. An example
would be to keep insiders from leaking information to
-competitors. An instance of such an access control system is
-the secrecy levels used in the military. There you distinguish
-usually four secrecy levels:
+competitors. The secrecy levels used in the military are an
+instance of such an access control system. There you
+distinguish usually four secrecy levels:
\begin{itemize}
\item top secret
@@ -365,6 +466,17 @@
\includegraphics[scale=0.45]{../pics/pointsplane.jpg}
\end{center}
+%\begin{center}
+%\begin{tikzpicture}
%
+% \draw[->,line width=0.5mm] (0,0,0) -- (2,0,0);
% \draw[->,line width=0.5mm] (0,0,0) -- (0,2,0);
% \draw[->,line width=0.5mm] (0,0,0) -- (0,0,2);
+%
+% \path[draw] (-1,-4) to[out=20,in=220] (3,3);
+% \path[draw] (6,-7) to[out=40,in=210] (9,1);
+% \path[draw] (-1,-4) to[out=0,in=80] (6,-7);
+% \path[draw] (3,3) to[out=10,in=140] (9,1);
+%
%\end{tikzpicture}
+%\end{center}
+
\noindent The idea is to use the points as keys for each level
of shared access. The CEO gets the point directly. The MDs get
keys lying on a line and the Ds get keys lying on the plane.