5 |
the Hurd servers. Several system servers support the C library. |
the Hurd servers. Several system servers support the C library. |
6 |
|
|
7 |
|
|
8 |
|
\section{Authentication} |
9 |
|
\label{auth} |
10 |
|
|
11 |
|
Capabilities are a good way to give access to protected objects and |
12 |
|
services. They are flexible, lightweight and generic. However, Unix |
13 |
|
traditionally uses access control lists (ACL) to restrict access to |
14 |
|
objects like files. Any task running with a certain user ID can |
15 |
|
access all files that are readable for the user with that user ID. |
16 |
|
Although all objects are implemented as capabilities in the Hurd, the |
17 |
|
Hurd also supports the use of user IDs for access control. |
18 |
|
|
19 |
|
The system authentication server \texttt{auth} implements the Unix |
20 |
|
authentication scheme using capabilities. It provides auth |
21 |
|
capabilities, which are associated with a list of effective and |
22 |
|
available user and group IDs. The holder of such a capability can use |
23 |
|
it to authenticate itself to other servers, using the protocol below. |
24 |
|
|
25 |
|
Of course, these other servers must use (and trust) the same |
26 |
|
\texttt{auth} server as the user. Otherwise, the authentication will |
27 |
|
fail. Once a capability is authenticated in the server, the server |
28 |
|
will know the user IDs of the client, and can use them to validate |
29 |
|
further operations. |
30 |
|
|
31 |
|
The \texttt{auth} server provides two types of capabilities: |
32 |
|
|
33 |
|
\paragraph{Auth capabilities} |
34 |
|
An auth capability is associated with four vectors of IDs: The |
35 |
|
effective user and group IDs, which should be used by other servers to |
36 |
|
authenticate operations that require certain user or group IDs, and |
37 |
|
the available user and group IDs. Available IDs should not be used |
38 |
|
for authentication purposes, but can be turned into effective IDs by |
39 |
|
the holder of an auth capability at any time. |
40 |
|
|
41 |
|
New auth capabilities can be created from existing auth capabilities, |
42 |
|
but only if the requested IDs are a subsets from the union of the |
43 |
|
(effective and available) IDs in the provided auth capabilities. If |
44 |
|
an auth capability has an effective or available user ID 0, then |
45 |
|
arbitrary new auth objects can be created from that. |
46 |
|
|
47 |
|
\paragraph{Passport capabilities} |
48 |
|
A passport capability can be created from an auth capability and is |
49 |
|
only valid for the task that created it. It can be provided to a |
50 |
|
server in an authentication process (see below). For the client, the |
51 |
|
passport capability does not directly implement any useful operation. |
52 |
|
For the server, it can be used to verify the identity of a user and |
53 |
|
read out the effective user and group IDs. |
54 |
|
|
55 |
|
The auth server should always create new passport objects for |
56 |
|
different tasks, even if the underlying auth object is the same, so |
57 |
|
that a task having the passport capability can not spy on other tasks |
58 |
|
unless they were given the passport capability by that task. |
59 |
|
|
60 |
|
\subsection{Authenticating a client to a server} |
61 |
|
|
62 |
|
A client can authenticate itself to a server with the following |
63 |
|
protocol: |
64 |
|
|
65 |
|
\paragraph{Preconditions} |
66 |
|
The client $C$ has an auth capability implemented by the \texttt{auth} |
67 |
|
server $A$. It also has a capability implemented by the server $S$. |
68 |
|
It wants to reauthenticate this capability with the auth capability, |
69 |
|
so the server associates the new user and group IDs with it. |
70 |
|
|
71 |
|
The server also has an auth capability implemented by its trusted |
72 |
|
\texttt{auth} server. For the reauthentication to succeed, the |
73 |
|
\texttt{auth} server of the client and the server must be identical. |
74 |
|
If this is the case, the participating tasks hold task info caps for |
75 |
|
all other participating tasks (because of the capabilities they hold). |
76 |
|
|
77 |
|
\begin{enumerate} |
78 |
|
\item The client $C$ requests the passport capability for itself from |
79 |
|
the auth capability from $A$. |
80 |
|
|
81 |
|
\begin{comment} |
82 |
|
Normally, the client will request the passport capability only |
83 |
|
once and store it together with the auth capability. |
84 |
|
\end{comment} |
85 |
|
|
86 |
|
\item The \texttt{auth} server receives the request and creates a new |
87 |
|
passport capability for this auth capability and this client. The |
88 |
|
passport capability is returned to the user. |
89 |
|
|
90 |
|
\item The user receives the reply from the \texttt{auth} server. |
91 |
|
|
92 |
|
It then sends the reauthentication request to the server $S$, which |
93 |
|
is invoked on the capability the client wants to reauthenticate. It |
94 |
|
provides the passport capability as an argument. |
95 |
|
|
96 |
|
\item The server $S$ can accept the passport capability, if it |
97 |
|
verifies that it is really implemented by the \texttt{auth} server |
98 |
|
it trusts. If the client does not provide a passport capability to |
99 |
|
the trusted \texttt{auth} server, the authentication process is |
100 |
|
aborted with an error. |
101 |
|
|
102 |
|
Now the server can send a request to the \texttt{auth} server to |
103 |
|
validate the passport capability. The RPC is invoked on the |
104 |
|
passport capability. |
105 |
|
|
106 |
|
\item The \texttt{auth} server receives the validation request on the |
107 |
|
passport capability and returns the task ID of the client $C$ that |
108 |
|
this passport belongs to, and the effective user and group IDs for |
109 |
|
the auth cap to which this passport cap belongs. |
110 |
|
|
111 |
|
\begin{comment} |
112 |
|
The Hurd on Mach returned the available IDs as well. This feature |
113 |
|
is not used anywhere in the Hurd, and as the available IDs should |
114 |
|
not be used for authentication anyway, this does not seem to be |
115 |
|
useful. If it is needed, it can be added in an extended version |
116 |
|
of the validation RPC. |
117 |
|
\end{comment} |
118 |
|
|
119 |
|
\item The server receives the task ID and the effective user and group |
120 |
|
IDs. The server now verifies that the task ID is the same as the |
121 |
|
task ID of the sender of the reauthentication request. Only then |
122 |
|
was the reauthentication request made by the owner of the auth cap. |
123 |
|
It can then return a new capability authenticated with the new user |
124 |
|
and group IDs. |
125 |
|
|
126 |
|
\begin{comment} |
127 |
|
The verification of the client's task ID is necessary. As the |
128 |
|
passport cap is copied to other tasks, it can not serve as a proof |
129 |
|
of identity alone. It is of course absolutely crucial that the |
130 |
|
server holds the task info cap for the client task $C$ for the |
131 |
|
whole time of the protocol. But the same is actually true for any |
132 |
|
RPC, as the server needs to be sure that the reply message is sent |
133 |
|
to the sender thread (and not any imposter). |
134 |
|
\end{comment} |
135 |
|
|
136 |
|
\item The client receives the reply with the new, reauthenticated |
137 |
|
capability. Usually this capability is associated in the server |
138 |
|
with the same abstract object, but different user credentials. |
139 |
|
|
140 |
|
\begin{comment} |
141 |
|
Of course a new capability must be created. Otherwise, all other |
142 |
|
users holding the same capability would be affected as well. |
143 |
|
\end{comment} |
144 |
|
|
145 |
|
The client can now deallocate the passport cap. |
146 |
|
|
147 |
|
\begin{comment} |
148 |
|
As said before, normally the passport cap is cached by the client |
149 |
|
for other reauthentications. |
150 |
|
\end{comment} |
151 |
|
\end{enumerate} |
152 |
|
|
153 |
|
\paragraph{Result} |
154 |
|
The client $C$ has a new capability that is authenticated with the new |
155 |
|
effective user and group IDs. The server has obtained the effective |
156 |
|
user and group IDs from the \texttt{auth} server it trusts. |
157 |
|
|
158 |
|
\begin{comment} |
159 |
|
The Hurd on Mach uses a different protocol, which is more complex |
160 |
|
and is vulnerable to DoS attacks. The above protocol can not |
161 |
|
readily be used on Mach, because the sender task of a message can |
162 |
|
not be easily identified. |
163 |
|
\end{comment} |
164 |
|
|
165 |
|
|
166 |
\section{Process Management} |
\section{Process Management} |
167 |
\label{proc} |
\label{proc} |
168 |
|
|