handouts/ho04.tex
changeset 257 9bc912fcedb6
parent 252 fa151c0a3cf4
child 260 42bf66f0a903
equal deleted inserted replaced
256:e272713e34ff 257:9bc912fcedb6
    49 straightforward. No?
    49 straightforward. No?
    50 
    50 
    51 There are already some special rules for directories and
    51 There are already some special rules for directories and
    52 links. If the execute attribute of a directory is \emph{not}
    52 links. If the execute attribute of a directory is \emph{not}
    53 set, then one cannot change into the directory and one cannot
    53 set, then one cannot change into the directory and one cannot
    54 access any file inside it. If the write attribute is not set,
    54 access any file inside it. If the write attribute is
    55 then one can change existing files (provide they are
    55 \emph{not} set, then one can change existing files (provide
    56 changeable), but one cannot create new files. If the read
    56 they are changeable), but one cannot create new files. If the
    57 attribute is not set, one cannot search inside the directory
    57 read attribute is \emph{not} set, one cannot search inside the
    58 (\pcode{ls -la} does not work) but one can access an existing
    58 directory (\pcode{ls -la} does not work) but one can access an
    59 file, provided one knows its name. Links to files never depend
    59 existing file, provided one knows its name. Links to files
    60 on the permission of the link, but the file they are pointing
    60 never depend on the permission of the link, but the file they
    61 to.
    61 are pointing to. Otherwise one could easily change access
       
    62 rights to files.
    62 
    63 
    63 While the above might sound already moderately complicated,
    64 While the above might sound already moderately complicated,
    64 the real complications with Unix-style file permissions
    65 the real complications with Unix-style file permissions
    65 involve the setuid and setgid attributes. For example the file
    66 involve the setuid and setgid attributes. For example the file
    66 \pcode{microedit} in Line 5 has the setuid attribute set
    67 \pcode{microedit} in Line 5 has the setuid attribute set
    93 \noindent This will typically involve quite a lot of programs
    94 \noindent This will typically involve quite a lot of programs
    94 on a Unix system. I counted 90 programs with the setuid
    95 on a Unix system. I counted 90 programs with the setuid
    95 attribute set on my bog-standard Mac OSX system (including the
    96 attribute set on my bog-standard Mac OSX system (including the
    96 program \pcode{/usr/bin/login} for example). The problem is
    97 program \pcode{/usr/bin/login} for example). The problem is
    97 that if there is a security problem with only one of them, be
    98 that if there is a security problem with only one of them, be
    98 it a buffer overflow for example, then malicious users 
    99 it a buffer overflow for example, then malicious users can
    99 can gain root access (and for outside attackers it is much
   100 gain root access (and for outside attackers it is much easier
   100 easier to take over a system). Unfortunately it is rather easy 
   101 to take over a system). Unfortunately it is rather easy to
   101 to make errors since the handling of elevating and dropping 
   102 cause a security problem since the handling of elevating and
   102 access rights in such programs rests entirely with the 
   103 dropping access rights in such programs rests entirely with
   103 programmer.
   104 the programmer.
   104 
   105 
   105 The fundamental idea behind the setuid attribute is that a
   106 The fundamental idea behind the setuid attribute is that a
   106 file will be able to run not with the callers access rights,
   107 file will be able to run not with the callers access rights,
   107 but with the rights of the owner of the file. So
   108 but with the rights of the owner of the file. So
   108 \pcode{/usr/bin/login} will always be running with root access
   109 \pcode{/usr/bin/login} will always be running with root access
   156 elevated to \pcode{root}, but the program itself must make
   157 elevated to \pcode{root}, but the program itself must make
   157 this change. After it has done the work, the effective
   158 this change. After it has done the work, the effective
   158 identity should go back to the real identity.
   159 identity should go back to the real identity.
   159 
   160 
   160 
   161 
   161 Despite these complicated semantics, Unix-style access control
   162 Despite this complicated semantics, Unix-style access control
   162 is of no use in a number of situations. For example it cannot
   163 is of no use in a number of situations. For example it cannot
   163 be used to exclude some subset of people, but otherwise have
   164 be used to exclude some subset of people, but otherwise have
   164 files readable by everybody else (say you want to restrict
   165 files readable by everybody else (say you want to restrict
   165 access to a file such that your office mates cannot access 
   166 access to a file such that your office mates cannot access 
   166 a file). You could try setting the group of the file to this
   167 a file). You could try setting the group of the file to this
   167 subset and then restrict access accordingly. But this does not
   168 subset and then restrict access accordingly. But this does not
   168 help, because users can drop membership in groups. 
   169 help, because users can drop membership in groups. If one
       
   170 needs such fine-grained control over who can access a file,
       
   171 one needs more powerful \emph{mandatory access controls}
       
   172 as described next.
       
   173 
   169 
   174 
   170 \subsubsection*{Secrecy and Integrity}
   175 \subsubsection*{Secrecy and Integrity}
   171 
   176 
   172 
   177 Often you need to keep information secret within a system or
       
   178 organisation, or secret to the ``outside world''. An example
       
   179 would be to keep information secret such that insiders cannot
       
   180 leak information to competitors. A very good instance of such
       
   181 an access control system is the secrecy levels used in the
       
   182 military. There you distinguish four secrecy levels:
       
   183 
       
   184 \begin{itemize}
       
   185 \item top secret
       
   186 \item secret
       
   187 \item confidential
       
   188 \item unclassified
       
   189 \end{itemize}
       
   190 
       
   191 The idea is that the secrets classified as top-secret are most
       
   192 closely guarded and only accessible to people who have a
       
   193 special clearance. The unclassified category is the lowest
       
   194 level not needing any clearance. While the idea behind these
       
   195 security levels is quite straightforward, there are some
       
   196 interesting implications for when you want to realise such a
       
   197 system. To begin the access control needs to be
       
   198 \emph{mandatory} as opposed to \emph{discretionary}. With
       
   199 discretionary access control, the users can decide how to
       
   200 restrict or grant access to resources. With mandatory access
       
   201 control, the access to resources is enforced ``system-wide''
       
   202 and cannot be controlled by the user. There are also some
       
   203 interesting rules for reading and writing an object that 
       
   204 need to be enforced: 
       
   205 
       
   206 
       
   207 \begin{itemize}
       
   208 \item {\bf Read Rule}: a principal $P$ can read an object $O$
       
   209 provided $P$'s security level is at least as high as $O$'s
       
   210 
       
   211 \item {\bf Write Rule}: a principal $P$ can write an object $O$
       
   212 provided $O$'s security level is at least as high as $P$'s 
       
   213 \end{itemize} 
       
   214 
       
   215 \noindent The first rule says that a principal with secret
       
   216 clearance can read secret documents or lower, but not
       
   217 documents classified top-secret. The second rule for writing
       
   218 needs to be the other way around: someone with secret
       
   219 clearance can write secret or top-secret documents---no
       
   220 information is leaked. In contrast it cannot write
       
   221 confidential documents, because then information can be leaked
       
   222 to lower levels. These rules about enforcing secrecy with
       
   223 mult-level clearances is often called \emph{Bell/LaPudela}
       
   224 model, named after two people who studied such systems.
       
   225 
       
   226 A problem with this access control system is when two people
       
   227 want to talk to each other but having different security
       
   228 clearances, say secret and confidential. In these situations,
       
   229 the people with the higher clearance have to lower their
       
   230 security level and are not allowed to take any document
       
   231 from the higher level with them (otherwise again information
       
   232 could be leaked). In actual systems this might mean that
       
   233 people need to log out and log into the system again---this
       
   234 time with credentials for the lower level.
       
   235 
       
   236 While secrecy is one property you often want to enforce,
       
   237 integrity is another. This property ensures that no
   173 
   238 
   174 \subsubsection*{Further Information}
   239 \subsubsection*{Further Information}
   175 
   240 
   176 If you want to know more about the intricacies of the
   241 If you want to know more about the intricacies of the
   177 ``simple'' Unix access control system you might find the
   242 ``simple'' Unix access control system you might find the