9 \section*{Handout 4 (Access Control)} |
9 \section*{Handout 4 (Access Control)} |
10 |
10 |
11 Access control is essentially about deciding whether to grant |
11 Access control is essentially about deciding whether to grant |
12 access to a resource or deny it. Sounds easy. No? Well it |
12 access to a resource or deny it. Sounds easy. No? Well it |
13 turns out that things are not as simple as they seem at first |
13 turns out that things are not as simple as they seem at first |
14 glance. Let us first look as a case-study at how access |
14 glance. Let us first look, as a case-study, at how access |
15 control is organised in Unix-like systems (Windows systems |
15 control is organised in Unix-like systems (Windows systems |
16 have similar access controls, although the details might be |
16 have similar access controls, although the details might be |
17 quite different). |
17 quite different). |
18 |
18 |
19 |
19 |
101 to make errors since the handling of elevating and dropping |
101 to make errors since the handling of elevating and dropping |
102 access rights in such programs rests entirely with the |
102 access rights in such programs rests entirely with the |
103 programmer. |
103 programmer. |
104 |
104 |
105 The fundamental idea behind the setuid attribute is that a |
105 The fundamental idea behind the setuid attribute is that a |
106 file with this attribute will be able to run not with the |
106 file will be able to run not with the callers access rights, |
107 callers access rights, but with the rights of the owner of the |
107 but with the rights of the owner of the file. So |
108 file. So \pcode{/usr/bin/login} will always be running with |
108 \pcode{/usr/bin/login} will always be running with root access |
109 root access rights, no matter who invokes this program. The |
109 rights, no matter who invokes this program. The problem is |
110 problem is that this entails a rather complicated semantics of |
110 that this entails a rather complicated semantics of what the |
111 what the identity of a process (that runs the program) is. One |
111 identity of a process (that runs the program) is. One would |
112 would hope there is only one such ID, but in fact Unix |
112 hope there is only one such ID, but in fact Unix distinguishes |
113 distinguishes three(!): |
113 three(!): |
114 |
114 |
115 \begin{itemize} |
115 \begin{itemize} |
116 \item \emph{real identity}\\ |
116 \item \emph{real identity}\\ |
117 This is the ID of the user who creates |
117 This is the ID of the user who creates |
118 the process; can only be changed to something else by root. |
118 the process; can only be changed to something else by root. |