6 \fnote{\copyright{} Christian Urban, 2014}

     6 \fnote{\copyright{} Christian Urban, 2014, 2015}

    18 at shared access control in multi-agent systems.

    18 at shared access control in multi-agent systems. But before we

    19 

    19 start, let us motivate access control systems by the kind of

    20 attacks we have seen in the last lecture. \bigskip

    21 

    22 \noindent There are two further general approaches for

    23 countering buffer overflow attacks (and other similar

    24 attacks). One are Unix-like access controls, which enable a

    25 particular architecture for network applications, for example

    26 web-servers. This architecture minimises the attack surface

    27 that is visible from, for example, the Internet. And if an

    28 attack occurs the architecture attempts to limit the damage.

    29 The other approach is to \emph{radically} minimise the attack

    30 surface by running only the bare essentials on the web-server.

    31 In this approach, even the operating system is eliminated.

    32 This approach is called \emph{unikernel}. 

    33 

    34 A \emph{unikernel} is essentially a single, fixed purpose

    35 program running on a server. Nothing else is running on the

    36 server, except potentially many instances of this single

    37 program are run concurrently with the help of a

    38 hypervisor.\footnote{Xen is a popular hypervisor; it provides

    39 the mechanism of several virtual machines on a single

    40 computer.} This single program implements the functionality

    41 the server offers (for example serving web-pages). The main

    42 point is that all the services the operating system normally

    43 provides (network stack, file system, ssh and so on) are not

    44 used by default in unikernels. Instead, the single program

    45 uses libraries (the unikernel) whenever some essential

    46 functionality is needed. The developer only needs to select a

    47 minimal set of these libraries in order to implement a server

    48 for web-pages, for example. In this way, ssh, say, is only

    49 provided, when it is absolutely necessary.

    50 

    51 Unikernels are a rather recent idea for hardening servers. I

    52 have not seen any production use of this idea, but there are

    53 plenty of examples from academia. The advantage of unikernels

    54 is the rather small footprint in terms of memory, booting

    55 times and so on (no big operating system is needed). This

    56 allows unikernels to run on low-coast hardware such as

    57 Raspberry Pis or Cubieboards, where they can replace much more

    58 expensive hardware for the same purpose. The low booting times

    59 of unikernels are also an advantage when your server needs to

    60 scale up to higher user-demands. Then it is often possible to

    61 just run another instance of the single program, which can be

    62 started almost instantly without the user seeing any delay

    63 (unlike if you have to start, say, Windows and then on top of

    64 that start your network application). One of the most

    65 well-known examples of a unikernel is MirageOS available from

    66 

    67 \begin{center}

    68 \url{https://mirage.io}

    69 \end{center}

    70  

    71 \noindent This unikernel is based on the functional

    72 programming language Ocaml, which provides added security

    73 (Ocaml does not allow buffer overflow attacks, for example).

    74 If you want to test the security of MirageOS, the 

    75 developers issued a Bitcoin challenge: if you can break into 

    76 their system, you can get 10 Bitcoins

    77 

    78 \begin{center}

    79 \url{http://ownme.ipredator.se}

    80 \end{center}

    81 

    82 However, sometimes you cannot, or do not want to, get rid of

    83 the operating system. In such cases it is still a good idea

    84 to minimise the attack surface. For this it helps if the

    85 network application can be split into two parts---an 

    86 application and an interface:

    87 

    88 \begin{center}

    89   \begin{tikzpicture}[scale=1]

    90   

    91   \draw[line width=1mm] (-.3, 0) rectangle (1.5,2);

    92   \draw (4.7,1) node {Internet};

    93   \draw (-2.7,1.7) node {\footnotesize Application};

    94   \draw (0.6,1.7) node {\footnotesize Interface};

    95   \draw (0.6,-0.4) node {\footnotesize \begin{tabular}{c}unprivileged\\[-1mm] process\end{tabular}};

    96   \draw (-2.7,-0.4) node {\footnotesize \begin{tabular}{c}privileged\\[-1mm] process\end{tabular}};

    97   

    98   \draw[line width=1mm] (-1.8, 0) rectangle (-3.6,2);

    99 

   100   \draw[white] (1.7,1) node (X) {};

   101   \draw[white] (3.7,1) node (Y) {};

   102   \draw[<->, line width = 2mm] (X) -- (Y);

   103  

   104   \draw[<->, line width = 1mm] (-0.6,1) -- (-1.6,1);

   105   \end{tikzpicture}

   106 \end{center}

   107 

   108 \noindent The idea is that all heavy-duty lifting in the

   109 application (for example database access) is done by a

   110 privileged process. All user input from the internet is

   111 received by an \emph{un}privileged process, which is

   112 restricted to only receive user input from the Internet and

   113 communicates with the privileged process. This communication,

   114 however, needs to be sanitised, meaning any unexpected

   115 user-input needs to be rejected. The idea behind this split is

   116 that if an attacker can take control of the

   117 \emph{un}privileged process, then he or she cannot do much

   118 damage. However, the split into such privileged and

   119 unprivileged processes requires an operating system that

   120 supports Unix-style access controls, which look at next.

    52 This

   153 This relatively fine granularity of owner, group, everybody

    53 relatively fine granularity of owner, group, everybody else

   154 else seems to cover many useful scenarios of access control. A

    54 seems to cover many useful scenarios of access control. A

   120 program \pcode{/usr/bin/login} for example). The problem is

   221 program \pcode{/usr/bin/login}). The problem is that if there

   121 that if there is a security problem with only one of them, be

   222 is a security problem with only one of them, be it a buffer

   122 it a buffer overflow for example, then malicious users can

   223 overflow for example, then malicious users can gain root

   123 gain root access (and for outside attackers it is much easier

   224 access (and for outside attackers it is much easier to take

   124 to take over a system). Unfortunately it is rather easy to

   225 over a system). Unfortunately it is rather easy to cause a

   125 cause a security problem since the handling of elevating and

   226 security problem since the handling of elevating and dropping

   126 dropping access rights in such programs rests entirely with

   227 access rights in such programs rests entirely with the

   127 the programmer.

   228 programmer.

   223 competitors. An instance of such an access control system is

   324 competitors. The secrecy levels used in the military are an

   224 the secrecy levels used in the military. There you distinguish

   325 instance of such an access control system. There you

   225 usually four secrecy levels:

   326 distinguish usually four secrecy levels: