# HG changeset patch # User Christian Urban # Date 1413733471 -3600 # Node ID 64e62d63673788cff20a42d492bc7a8c67e2bfa7 # Parent bf45386496195daac29d9b042fded938f41e57d5 updated diff -r bf4538649619 -r 64e62d636737 handouts/ho04.pdf Binary file handouts/ho04.pdf has changed diff -r bf4538649619 -r 64e62d636737 handouts/ho04.tex --- a/handouts/ho04.tex Sun Oct 19 16:02:36 2014 +0100 +++ b/handouts/ho04.tex Sun Oct 19 16:44:31 2014 +0100 @@ -24,12 +24,13 @@ 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. This relatively fine granularity seems to -cover many cases of access control. A typical example of some -files with permission attributes is as follows: +access: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite +and e\underline{\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. This +relatively fine granularity seems to cover many useful +scenarios of access control. A typical example of some files +with permission attributes is as follows: {\small\lstinputlisting[language={}]{../slides/lst}} @@ -39,12 +40,12 @@ 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 +can read and write \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 and @@ -74,9 +75,10 @@ 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 +internal data structures of the operating system, which only +root should be allowed to. 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 @@ -91,18 +93,22 @@ \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}). 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 (or outside -attackers) can gain root access. +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. -The idea for files that have the setuid attribute set is -that when running such files they will run not with the -callers access rights, but with the owner of the files rights. -So \pcode{/usr/bin/login} will always be running with root -access rights, no matter who invokes this program. The problem -is that this entails a rather complicated semantics of what -the identity of a process (that runs the program) is. One +The fundamental idea behind the setuid attribute is that a +file with this attribute 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 access rights, no matter who invokes this program. The +problem is that this entails a rather complicated semantics of +what the identity of a process (that runs the program) is. One would hope there is only one such ID, but in fact Unix distinguishes three(!): @@ -123,9 +129,9 @@ saved identity will be the real identity. \end{itemize} -\noindent As an example consider again \pcode{passwd} program. -When started by, say the user \pcode{foo}, it has at the -beginning the identities: +\noindent As an example consider again the \pcode{passwd} +program. When started by, say the user \pcode{foo}, it has at +the beginning the identities: \begin{itemize} \item \emph{real identity}: \pcode{foo}\\ @@ -143,14 +149,23 @@ \end{itemize} \noindent It can now read and write the file -\pcode{/etc/passwd}. Note the effective identity is not -automatically elevated to \pcode{root}, but the program itself -must make this change. After it has done the work, the -effective identity goes back to the real identity. +\pcode{/etc/passwd}. After finishing the job it is supposed to +drop the effective identity back to \pcode{foo}. This is the +responsibility of the programmers who wrote \pcode{passwd}. +Notice that the effective identity is not automatically +elevated to \pcode{root}, but the program itself must make +this change. After it has done the work, the effective +identity should go back to the real identity. - -Cannot be used to exclude some people +Despite these 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. \subsubsection*{Secrecy and Integrity}