\documentclass{article}\usepackage{../style}\usepackage{../langs}\begin{document}\fnote{\copyright{} Christian Urban, King's College London, 2014, 2015}\section*{Handout 4 (Access Control)}Access control is essentially about deciding whether to grantaccess to a resource or deny it. Sounds easy, no? Well itturns out that things are not as simple as they seem at firstglance. Let us first look, as a case-study, at how accesscontrol is organised in Unix-like systems (Windows systemshave similar access controls, although the details might bequite different). Then we have a look at how secrecy andintegrity can be ensured in a system, and finally have a lookat shared access control in multi-agent systems. But before westart, let us motivate access control systems by the kind ofattacks we have seen in the last lecture. \bigskip\noindent There are two further general approaches forcountering buffer overflow attacks (and other similarattacks). One are Unix-like access controls, which enable aparticular architecture for network applications, for exampleweb-servers. This architecture minimises the attack surfacethat is visible from, for example, the Internet. And if anattack occurs the architecture attempts to limit the damage.The other approach is to \emph{radically} minimise the attacksurface 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 purposeprogram running on a server. Nothing else is running on theserver, except potentially many instances of this singleprogram are run concurrently with the help of ahypervisor.\footnote{Xen is a popular hypervisor; it providesthe mechanism of several virtual machines on a singlecomputer.} This single program implements the functionalitythe server offers (for example serving web-pages). The mainpoint is that all the services the operating system normallyprovides (network stack, file system, ssh and so on) are notused by default in unikernels. Instead, the single programuses libraries (the unikernel) whenever some essentialfunctionality is needed. The developer only needs to select aminimal set of these libraries in order to implement a serverfor web-pages, for example. In this way, ssh, say, is onlyprovided, when it is absolutely necessary.Unikernels are a rather recent idea for hardening servers. Ihave not seen any production use of this idea, but there areplenty of examples from academia. The advantage of unikernelsis the rather small footprint in terms of memory, bootingtimes and so on (no big operating system is needed). Thisallows unikernels to run on low-coast hardware such asRaspberry Pi's or Cubieboards, where they can replace much moreexpensive hardware for the same purpose. The low booting timesof unikernels are also an advantage when your server needs toscale up to higher user-demands. Then it is often possible tojust run another instance of the single program, which can bestarted almost instantly without the user seeing any delay(unlike if you have to start, say, Windows and then on top ofthat start your network application). One of the mostwell-known examples of a unikernel is MirageOS available from\begin{center}\url{https://mirage.io}\end{center}\noindent This unikernel is based on the functionalprogramming 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 at\begin{center}\url{http://ownme.ipredator.se}\end{center}\noindent you can get 10 Bitcoins. This is approximately \pounds{}41,000. However, sometimes you cannot, or do not want to, get rid ofthe operating system. In such cases it is still a good ideato minimise the attack surface. For this it helps if thenetwork 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.5) node {\footnotesize \begin{tabular}{c}Application\\(dangerous part)\end{tabular}}; \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.6, 0) rectangle (-3.8,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.4,1) -- (-1.5,1); \end{tikzpicture}\end{center}\noindent The idea is that all heavy-duty lifting, ordangerous operations, in the application (for example databaseaccess or writing a file) is done by a privileged process. All user input fromthe internet is received by an \emph{un}privileged process,which is restricted to only receive user input from theInternet and communicates with the privileged process. Thiscommunication, however, needs to be sanitised, meaning anyunexpected user-input needs to be rejected. The idea behindthis split is that if an attacker can take control of the\emph{un}privileged process, then he or she cannot do muchdamage. However, the split into such privileged andunprivileged process requires an operating system thatsupports Unix-style access controls, which we will look at next.\subsubsection*{Unix-Style Access Control}Following the Unix-philosophy that everything is considered asa file, even memory, ports and so on, access control in Unixis organised around 11 Bits that specify how a file can beaccessed. These Bits are sometimes called the \emph{permissionattributes} of a file. There are typically three modes foraccess: \underline{\textbf{r}}ead, \underline{\textbf{w}}riteand e\underline{\textbf{x}}ecute. Moreover there are threeuser groups to which the modes apply: the owner of the file,the group the file is associated with and everybody else. A typical permission of a file owned by \texttt{bob} being in the group \texttt{staff} might look as follows:\begin{center}${\underbrace{\LARGE\texttt{-}}_{\text{\makebox[0mm]{directory}}}} \;{\underbrace{\LARGE\texttt{r{}-{}-}}_{\text{user}}}\, {\underbrace{\LARGE\texttt{r{}w{}-}}_{\text{group}}}\, {\underbrace{\LARGE\texttt{r{}w{}x}}_{\text{other}}}\;\;\; \LARGE\texttt{bob}\;\;\;\texttt{staff}$\end{center}\noindent For the moment let us ignore the directory bit. TheUnix access rules imply that Bob will only have read access tothis file, even if he is in the group \texttt{staff} and thisgroup's access permissions allow read and write. Similarly everymember in the \texttt{staff} group who is not \texttt{bob},will only have read-write access permissions, notread-write-execute.This relatively fine granularity of owner, group, everybodyelse seems to cover many useful scenarios of access control. Atypical example of some files with permission attributes is asfollows:{\small\lstinputlisting[language={}]{../slides/lst}}\noindent The leading \pcode{d} in Lines 2 and 6 indicate thatthe 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. Thesecond to fourth letter specify how the owner of the file canaccess the file. For example Line 3 states that \pcode{ping}can read and write \pcode{manual.txt}, but cannot execute it.The next three letters specify how the group members of thefile can access the file. In Line 4, for example, all studentscan read and write the file \pcode{report.txt}. Finally thelast three letters specify how everybody else can access afile. This should all be relatively familiar andstraightforward. No?There are already some special rules for directories andlinks. If the execute attribute of a directory is \emph{not}set, then one cannot change into the directory and one cannotaccess any file inside it. If the write attribute is\emph{not} set, then one can change existing files (providedthey are changeable), but one cannot create new files. If theread attribute is \emph{not} set, one cannot search inside thedirectory (\pcode{ls -la} does not work) but one can access anexisting file, provided one knows its name. Links to filesnever depend on the permission of the link, but the file theyare pointing to. Otherwise one could easily change accessrights to files.While the above might sound already moderately complicated,the real complications with Unix-style file permissionsinvolve 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 followingpuzzle: The program \pcode{passwd} allows users to changetheir passwords. Therefore \pcode{passwd} needs to have writeaccess to the file \pcode{/etc/passwd}. But this file cannotbe writable for every user, otherwise anyone can set anyoneelse's password. So changing securely passwords cannot beachieved with the simple Unix access rights discussed so far.While this situation might look like an anomaly, it is in factan often occurring problem. For example looking at currentactive processes with \pcode{/bin/ps} requires access tointernal data structures of the operating system, which onlyroot should have access to. In fact any of the followingactions cannot be configured for single users, but needprivileged root access\begin{itemize}\item changing system databases (users, groups, routing tablesand so on)\item opening a network port below 1024\item interacting with peripheral hardware, such as printers, harddisk etc\item overwriting operating system facilities, likeprocess scheduling and memory management\end{itemize}\noindent This will typically involve quite a lot of programson a Unix system. I counted 90 programs with the setuidattribute set on my bog-standard Mac OSX system (including theprogram \pcode{/usr/bin/login}). The problem is that if thereis a security problem with only one of them, be it a bufferoverflow for example, then malicious users can gain rootaccess (and for outside attackers it is much easier to takeover a system). Unfortunately it is rather easy to cause asecurity problem since the handling of elevating and droppingaccess rights in such programs rests entirely with theprogrammer.The fundamental idea behind the setuid attribute is that afile will be able to run not with the callers access rights,but with the rights of the owner of the file. So\pcode{/usr/bin/login} will always be running with root accessrights, no matter who invokes this program. The problem isthat this entails a rather complicated semantics of what theidentity of a process (that runs the program) is. One wouldhope there is only one such ID, but in fact Unix distinguishesthree(!):\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 eitherthe 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 startedwith the real identity of the user who started the program,and the identity of the owner of the program as effective andsaved identity. If the setuid bit is not set, then thesaved identity will be the real identity. \end{itemize}\noindent As an example consider again the \pcode{passwd}program. When started by, say the user \pcode{foo}, it has atthe 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 effectiveidentity 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}. After finishing the job it is supposed todrop the effective identity back to \pcode{foo}. This is theresponsibility of the programmers who wrote \pcode{passwd}.Notice that the effective identity is not automaticallyelevated to \pcode{root}, but the program itself must makethis change. After it has done the work, the effectiveidentity should go back to the real identity.If you want to play more with access rights in Unix, you canuse the program in Figure~\ref{test}. It explicitly checks forreadability and writability of files. The \pcode{main}function is organised into two parts: the first checksreadability and writability with the permissions according toa potential setuid bit, and the second (starting in Line 34)when the permissions are lowered to the caller. Note that thisprogram has one problem as well: it only gives a reliableanswer in cases a file is {\bf not} readable or {\bf not}writable when it returns an error code 13 (permission denied).It sometimes claims a file is not writable, say, but with anerror code 26 (text file busy). This is unrelated to thepermissions of the file.\begin{figure}[p]\small\lstinputlisting[language=C]{../progs/read.c}\caption{A read/write test program in C. It returns errno = 13 in cases when permission is denied.\label{test}}\end{figure}Despite this complicated semantics, Unix-style access controlis of no use in a number of situations. For example it cannotbe used to exclude some subset of people, but otherwise havefiles readable by everybody else (say you want to restrictaccess to a file such that your office mates cannot access afile). You could try setting the group of the file to thissubset and then restrict access accordingly. But this does nothelp, because users can drop membership in groups. If oneneeds such fine-grained control over who can access a file,one needs more powerful \emph{mandatory access controls} asdescribed next.\subsubsection*{Secrecy and Integrity}Often you need to keep information secret within a system ororganisation, or secret from the ``outside world''. An examplewould be to keep insiders from leaking information tocompetitors. The secrecy levels used in the military are aninstance of such an access control system. There youdistinguish usually 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 mostclosely guarded and only accessible to people who have aspecial clearance. The unclassified category is the lowestlevel not needing any clearance. While the idea behind thesesecurity levels is quite straightforward, there are someinteresting phenomenons that you need to think about whenrealising such a system. First this kind of access controlneeds to be \emph{mandatory} as opposed to\emph{discretionary}. With discretionary access control, theusers can decide how to restrict or grant access to resources.With mandatory access control, the access to resources isenforced ``system-wide'' and cannot be controlled by the user.There would be no point to let users set the secrecy level,because if they want to leak information they would set it tothe lowest. Even if there is no malicious intent, it couldhappen that somebody by accident sets the secrecy level toolow for a document. Note also that the secrecy levels are intension with the Unix-style access controls. There root isallowed to do everything, but in a system enforcing secrecy,you might not like to give root such powers. There are also some interesting rules for reading and writinga resource that need to be enforced: \begin{itemize}\item {\bf Read Rule}: a principal $P$ can read a resource $O$ provided $P$'s security level is at least as high as $O$'s\item {\bf Write Rule}: a principal $P$ can write a resource $O$ provided $O$'s security level is at least as high as $P$'s \end{itemize} \noindent The first rule implies that a principal with secretclearance can read secret documents or lower, but notdocuments classified top-secret. The second rule for writingneeds to be the other way around: someone with secretclearance can write secret or top-secret documents---noinformation is leaked in these cases. In contrast theprincipal cannot write confidential documents, because theninformation can be leaked to lower levels. These rules aboutenforcing secrecy with multi-level clearances are often called\emph{Bell/LaPadula} model, named after two people who studiedsuch systems.A problem with this kind of access control system is when twopeople want to talk to each other but are assigned differentsecurity clearances, say secret and confidential. In thesesituations, the people with the higher clearance have to lowertheir security level and are not allowed to take any documentfrom the higher level with them to the lower level (otherwiseinformation could be leaked). In actual systems, thismight mean that people need to log out and log into the systemagain---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 nobodywithout adequate clearance can change, or tamper with,systems. An example for this property is a \emph{fire-wall},which isolates a local system from threads from the Internet, for example. The rule for such a system isthat somebody from inside the fire-wall can write resourcesoutside the firewall, but you cannot write a resource inside the fire-wall from outside. Otherwise an outside can justtamper with a system in order to break in. In contrastwe can read resources from inside the fire-wall, for exampleweb-pages. But we cannot read anything from outside the fire-wall. Lest we might introduce a virus into the system(behind the fire-wall). In effect in order to ensureintegrity the read and write rules are reversed from thecase of secrecy:\begin{itemize}\item {\bf Read Rule}: a principal $P$ can read a resource $O$ provided $P$'s security level is lower or equal than $O$'s\item {\bf Write Rule}: a principal $P$ can write a resource $O$ provided $O$'s security level is lower or equal than $P$'s \end{itemize} \noindent This kind of access control system is called\emph{Biba} model, named after Kenneth Biba. Its purpose is toprevent data modification by unauthorised principals.The somewhat paradoxical result of the different reading andwriting rules in the \emph{\mbox{Bell}/LaPadula} and\emph{Biba} models is that we cannot have secrecy andintegrity at the same time in a system, or they need to beenforced by different means.\subsubsection*{Multi-Agent Access Control}In military or banking, for example, very critical decisionsneed to be made using a \emph{two-people rule}. This means suchdecisions need to be taken by two people together, so that nosingle person can defraud a bank or start a nuclear war (youwill know what I mean if you have seen the classic movie ``DrStrangelove or: How I Learned to Stop Worrying and Love theBomb''\footnote{\url{http://en.wikipedia.org/wiki/Dr._Strangelove}}).Translating the two-people rule into a software system seems notas straightforward as one might think.Let us assume we want to implement a system where CEOs canmake decisions on their own, for example whether or not tosell assets, but two managing directors (MDs) need to cometogether to make the same decision. If ``lowly'' directors(Ds) want to take this decision, three need to come together.Remember cryptographic keys are just sequences of bits. Anaive solution to the problem above is to split the necessarykey into $n$ parts according to the ``level'' where thedecision is taken. For example one complete key for a CEO, halves of the key for the MDs and thirds for the Ds. Theproblem with this kind of sharing a key is that there might bemany hundreds MDs and Ds in your organisations. Simple-mindedhalving or division by three of the key just does not work.A much more clever solution was proposed by Blakley and Shamirin 1979. This solution is inspired by some simple geometriclaws. Suppose a three-dimensional axis system. We can, clearly,specify a point on the $z$-axis, say, by specifying itscoordinates. But we could equally specify this point by a linethat intersects the $z$-axis in this point. How can a line bespecified? Well, by giving two points in space. But as youmight remember from school days, we can specify the point alsoby a plane intersecting the $z$-axis and a plane can bespecified by three points in space. This could be pictured asfollows:\begin{center}\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 levelof shared access. The CEO gets the point directly. The MDs getkeys lying on a line and the Ds get keys lying on the plane.Clever, no? Scaling this idea to more dimensions allows foreven more levels of access control and more interesting accessrules, like one MD and 2 Ds can take a decision together.Is such a shared access control used in practice? Wellmilitary command-chains are obviously organised like this.But in software systems often need to rely on data that mightnot be entirely accurate. So the CEO-level would correspondto the in-house data-source that you can trust completely.The MD-level would correspond to simple errors where you needthree inputs and you decide on what to do next according towhat at least two data-sources agree (the third source is then disregarded, because it is assumed it contains an error). If your data contains not just simple errors, youneed levels corresponding to Ds.\subsubsection*{Further Information}If you want to know more about the intricacies of the``simple'' Unix access control system you might find therelatively readable paper about ``Setuid Demystified'' useful.\begin{center}\small\url{http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf}\end{center}\noindent About secrecy and integrity, and shared accesscontrol I recommend to read the chapters on ``Nuclear Commandand Control'' and ``Multi-Level Security'' in Ross Anderson'sSecurity Engineering book (whose second edition is free).\end{document}%%% Local Variables: %%% mode: latex%%% TeX-master: t%%% End: