/[hurd]/hurd-l4/doc/posix.tex
ViewVC logotype

Diff of /hurd-l4/doc/posix.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by neal, Sun Sep 7 21:49:29 2003 UTC revision 1.2 by marcus, Sun Sep 7 22:24:06 2003 UTC
# Line 5  implemented in the GNU C library which u Line 5  implemented in the GNU C library which u
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    

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26