30 and everybody else. A typical example of some files with

    30 and everybody else. This relatively fine granularity seems to

    31 permission attributes is as follows:

    31 cover many cases of access control. A typical example of some

    32 files with permission attributes is as follows:

    49 There are already some special rules for directories. If the

    50 There are already some special rules for directories and

    50 execute attribute of a directory is \emph{not} set, then one

    51 links. If the execute attribute of a directory is \emph{not}

    51 cannot change into the directory and one cannot access any

    52 set, then one cannot change into the directory and one cannot

    52 file inside it. If the write attribute is not set, then one

    53 access any file inside it. If the write attribute is not set,

    53 can change existing files (provide they are changeable), but

    54 then one can change existing files (provide they are

    54 one cannot create new files. If the read attribute is not set,

    55 changeable), but one cannot create new files. If the read

    55 one cannot search inside the directory (\pcode{ls -la} does

    56 attribute is not set, one cannot search inside the directory

    56 not work) but one can access an existing file, provided one

    57 (\pcode{ls -la} does not work) but one can access an existing

    57 knows its name.

    58 file, provided one knows its name. Links to files never depend

    59 on the permission of the link, but the file they are pointing

    60 to.

    59 While the above might sound moderately complicated, the real

    62 While the above might sound already moderately complicated,

    60 complications with Unix-style file permissions involve the

    63 the real complications with Unix-style file permissions

    61 setuid and setgid attributes. For example the file

    64 involve the setuid and setgid attributes. For example the file

    88 \noindent This will typically involve quite a lot of

    91 \noindent This will typically involve quite a lot of programs

    89 programs on a Unix system. I counted 95 programs with the

    92 on a Unix system. I counted 90 programs with the setuid

    90 setuid attribute set on my bog-standard MacOSX system

    93 attribute set on my bog-standard Mac OSX system (including the

    91 (including the program \pcode{/usr/bin/login}).

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

    92 The problem is that if there is a security problem with

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

    93 one of them, then malicious users (or outside attackers)

    96 overflow for example, then malicious users (or outside

    94 can gain root access.

    97 attackers) can gain root access.

    96 The main rule for files that have the setuid attribute set is

    99 The idea for files that have the setuid attribute set is

   100 access rights, no matter who invokes this program.

   103 access rights, no matter who invokes this program. The problem

   104 is that this entails a rather complicated semantics of what 

   105 the identity of a process (that runs the program) is. One

   106 would hope there is only one such ID, but in fact Unix

   107 distinguishes three(!):

   108 

   109 \begin{itemize}

   110 \item \emph{real identity}\\ 

   111 This is the ID of the user who creates 

   112 the process; can only be changed to something else by root. 

   113 \item \emph{effective identity}\\ 

   114 This is the ID that is used to 

   115 grant or deny access to a resource; can be changed to either

   116 the real identity or saved identity by users, can be changed 

   117 to anything by root.

   118 \item \emph{saved identity}\\

   119 If the setuid bit set in a file then the process is started

   120 with the real identity of the user who started the program,

   121 and the identity of the owner of the program as effective and

   122 saved identity. If the setuid bit is not set, then the

   123 saved identity will be the real identity. 

   124 \end{itemize}

   125 

   126 \noindent As an example consider again \pcode{passwd} program.

   127 When started by, say the user \pcode{foo}, it has at the

   128 beginning the identities:

   129 

   130 \begin{itemize}

   131 \item \emph{real identity}: \pcode{foo}\\

   132 \emph{effective identity}: \pcode{foo}\\ 

   133 \emph{saved identity}: \pcode{root}

   134 \end{itemize}

   135 

   136 \noindent It is then allowed to change the effective

   137 identity to the saved identity to have

   138 

   139 \begin{itemize}

   140 \item \emph{real identity}: \pcode{foo}\\

   141 \emph{effective identity}: \pcode{root}\\ 

   142 \emph{saved identity}: \pcode{root}

   143 \end{itemize}

   144 

   145 \noindent It can now read and write the file

   146 \pcode{/etc/passwd}. Note the effective identity is not

   147 automatically elevated to \pcode{root}, but the program itself

   148 must make this change. After it has done the work, the

   149 effective identity goes back to the real identity.

   150 

   151 

   152 

   153 Cannot be used to exclude some people

   114 \url{http://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/downloads/setuid.pdf}

   167 \url{http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf}