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 |