22 Following the Unix-philosophy that everything is considered as |
22 Following the Unix-philosophy that everything is considered as |
23 a file, even memory, ports and so on, access control in Unix |
23 a file, even memory, ports and so on, access control in Unix |
24 is organised around 11 Bits that specify how a file can be |
24 is organised around 11 Bits that specify how a file can be |
25 accessed. These Bits are sometimes called the \emph{permission |
25 accessed. These Bits are sometimes called the \emph{permission |
26 attributes} of a file. There are typically three modes for |
26 attributes} of a file. There are typically three modes for |
27 access: \textbf{r}ead, \textbf{w}rite and e\textbf{x}ecute. |
27 access: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite |
28 Moreover there are three user groups to which the modes apply: |
28 and e\underline{\textbf{x}}ecute. Moreover there are three |
29 the owner of the file, the group the file is associated with |
29 user groups to which the modes apply: the owner of the file, |
30 and everybody else. This relatively fine granularity seems to |
30 the group the file is associated with and everybody else. This |
31 cover many cases of access control. A typical example of some |
31 relatively fine granularity seems to cover many useful |
32 files with permission attributes is as follows: |
32 scenarios of access control. A typical example of some files |
|
33 with permission attributes is as follows: |
33 |
34 |
34 {\small\lstinputlisting[language={}]{../slides/lst}} |
35 {\small\lstinputlisting[language={}]{../slides/lst}} |
35 |
36 |
36 \noindent The leading \pcode{d} in Lines 2 and 6 indicate that |
37 \noindent The leading \pcode{d} in Lines 2 and 6 indicate that |
37 the file is a directory, whereby in the Unix-tradition the |
38 the file is a directory, whereby in the Unix-tradition the |
38 \pcode{.} points to the directory itself. The \pcode{..} |
39 \pcode{.} points to the directory itself. The \pcode{..} |
39 points at the directory ``above'', or parent directory. The |
40 points at the directory ``above'', or parent directory. The |
40 second to fourth letter specify how the owner of the file can |
41 second to fourth letter specify how the owner of the file can |
41 access the file. For example Line 3 states that \pcode{ping} |
42 access the file. For example Line 3 states that \pcode{ping} |
42 can read and write the \pcode{manual.txt}, but cannot execute |
43 can read and write \pcode{manual.txt}, but cannot execute it. |
43 it. The next three letters specify how the group members of |
44 The next three letters specify how the group members of the |
44 the file can access the file. In Line 4, for example, all |
45 file can access the file. In Line 4, for example, all students |
45 students can read and write the file \pcode{report.txt}. |
46 can read and write the file \pcode{report.txt}. Finally the |
46 Finally the last three letters specify how everybody else can |
47 last three letters specify how everybody else can access a |
47 access a file. This should all be relatively familiar and |
48 file. This should all be relatively familiar and |
48 straightforward. No? |
49 straightforward. No? |
49 |
50 |
50 There are already some special rules for directories and |
51 There are already some special rules for directories and |
51 links. If the execute attribute of a directory is \emph{not} |
52 links. If the execute attribute of a directory is \emph{not} |
52 set, then one cannot change into the directory and one cannot |
53 set, then one cannot change into the directory and one cannot |
72 else's password. So changing securely passwords cannot be |
73 else's password. So changing securely passwords cannot be |
73 achieved with the simple Unix access rights discussed so far. |
74 achieved with the simple Unix access rights discussed so far. |
74 While this situation might look like an anomaly, it is in fact |
75 While this situation might look like an anomaly, it is in fact |
75 an often occurring problem. For example looking at current |
76 an often occurring problem. For example looking at current |
76 active processes with \pcode{/bin/ps} requires access to |
77 active processes with \pcode{/bin/ps} requires access to |
77 internal data structures of the operating system. In fact any |
78 internal data structures of the operating system, which only |
78 of the following actions cannot be configured for single |
79 root should be allowed to. In fact any of the following |
79 users, but need privileged root access |
80 actions cannot be configured for single users, but need |
|
81 privileged root access |
80 |
82 |
81 \begin{itemize} |
83 \begin{itemize} |
82 \item changing system databases (users, groups, routing tables |
84 \item changing system databases (users, groups, routing tables |
83 and so on) |
85 and so on) |
84 \item opening a network port below 1024 |
86 \item opening a network port below 1024 |
89 \end{itemize} |
91 \end{itemize} |
90 |
92 |
91 \noindent This will typically involve quite a lot of programs |
93 \noindent This will typically involve quite a lot of programs |
92 on a Unix system. I counted 90 programs with the setuid |
94 on a Unix system. I counted 90 programs with the setuid |
93 attribute set on my bog-standard Mac OSX system (including the |
95 attribute set on my bog-standard Mac OSX system (including the |
94 program \pcode{/usr/bin/login}). The problem is that if there |
96 program \pcode{/usr/bin/login} for example). The problem is |
95 is a security problem with only one of them, be it a buffer |
97 that if there is a security problem with only one of them, be |
96 overflow for example, then malicious users (or outside |
98 it a buffer overflow for example, then malicious users |
97 attackers) can gain root access. |
99 can gain root access (and for outside attackers it is much |
|
100 easier to take over a system). Unfortunately it is rather easy |
|
101 to make errors since the handling of elevating and dropping |
|
102 access rights in such programs rests entirely with the |
|
103 programmer. |
98 |
104 |
99 The idea for files that have the setuid attribute set is |
105 The fundamental idea behind the setuid attribute is that a |
100 that when running such files they will run not with the |
106 file with this attribute will be able to run not with the |
101 callers access rights, but with the owner of the files rights. |
107 callers access rights, but with the rights of the owner of the |
102 So \pcode{/usr/bin/login} will always be running with root |
108 file. So \pcode{/usr/bin/login} will always be running with |
103 access rights, no matter who invokes this program. The problem |
109 root access rights, no matter who invokes this program. The |
104 is that this entails a rather complicated semantics of what |
110 problem is that this entails a rather complicated semantics of |
105 the identity of a process (that runs the program) is. One |
111 what the identity of a process (that runs the program) is. One |
106 would hope there is only one such ID, but in fact Unix |
112 would hope there is only one such ID, but in fact Unix |
107 distinguishes three(!): |
113 distinguishes three(!): |
108 |
114 |
109 \begin{itemize} |
115 \begin{itemize} |
110 \item \emph{real identity}\\ |
116 \item \emph{real identity}\\ |
121 and the identity of the owner of the program as effective and |
127 and the identity of the owner of the program as effective and |
122 saved identity. If the setuid bit is not set, then the |
128 saved identity. If the setuid bit is not set, then the |
123 saved identity will be the real identity. |
129 saved identity will be the real identity. |
124 \end{itemize} |
130 \end{itemize} |
125 |
131 |
126 \noindent As an example consider again \pcode{passwd} program. |
132 \noindent As an example consider again the \pcode{passwd} |
127 When started by, say the user \pcode{foo}, it has at the |
133 program. When started by, say the user \pcode{foo}, it has at |
128 beginning the identities: |
134 the beginning the identities: |
129 |
135 |
130 \begin{itemize} |
136 \begin{itemize} |
131 \item \emph{real identity}: \pcode{foo}\\ |
137 \item \emph{real identity}: \pcode{foo}\\ |
132 \emph{effective identity}: \pcode{foo}\\ |
138 \emph{effective identity}: \pcode{foo}\\ |
133 \emph{saved identity}: \pcode{root} |
139 \emph{saved identity}: \pcode{root} |
141 \emph{effective identity}: \pcode{root}\\ |
147 \emph{effective identity}: \pcode{root}\\ |
142 \emph{saved identity}: \pcode{root} |
148 \emph{saved identity}: \pcode{root} |
143 \end{itemize} |
149 \end{itemize} |
144 |
150 |
145 \noindent It can now read and write the file |
151 \noindent It can now read and write the file |
146 \pcode{/etc/passwd}. Note the effective identity is not |
152 \pcode{/etc/passwd}. After finishing the job it is supposed to |
147 automatically elevated to \pcode{root}, but the program itself |
153 drop the effective identity back to \pcode{foo}. This is the |
148 must make this change. After it has done the work, the |
154 responsibility of the programmers who wrote \pcode{passwd}. |
149 effective identity goes back to the real identity. |
155 Notice that the effective identity is not automatically |
|
156 elevated to \pcode{root}, but the program itself must make |
|
157 this change. After it has done the work, the effective |
|
158 identity should go back to the real identity. |
150 |
159 |
151 |
160 |
152 |
161 Despite these complicated semantics, Unix-style access control |
153 Cannot be used to exclude some people |
162 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 files readable by everybody else (say you want to restrict |
|
165 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 subset and then restrict access accordingly. But this does not |
|
168 help, because users can drop membership in groups. |
154 |
169 |
155 \subsubsection*{Secrecy and Integrity} |
170 \subsubsection*{Secrecy and Integrity} |
156 |
171 |
157 |
172 |
158 |
173 |