The auth interface on L4-Hurd

[Wolfgang Jährling]

Hi!

In my understanding, an object handle will (on the client side) always
appear in combination with another number: The thread ID that is
responsible for the particular object.  This opens the question how
authentication will work with object handles; on Mach, the user creates
a new port as the first step.  We have three obvious possibilities, all
of which won't work:

- Simply giving a number to the server and letting both user and server
  pass this to auth in auth_*_authenticate obviously won't work, because
  an Evil Person might sabotage us, for example by doing lots of
  auth_server_authenticates and wait until auth matches one of these
  with the auth_user_authenticate call of some user.

- Give an object handle to the server that refers to a (nonexisting)
  object the user is "resposible" for.  Same problem as above, as the
  auth server has no clue about who was actually given that handle.

- We use an object handle that refers to an object in auth, i.e. we
  might do auth_makeauth on the client side to create a new object
  handle that is not associates with and IDs in auth, and give that (by
  copying, not giving it away entirely) to the server (we also need to
  notify auth about this, as usual).  In this way, the auth server would
  know who is allowed to do the auth_server_authenticate, no Evil person
  could do harm; we even get the additional bonus that the server will
  know which auth to contact if he holds object handles for multiple
  auth-servers.  But of course a) the server must not be allowed to do
  the auth_server_authenticate on the object handle he just got, which
  is impossible to make sure if we actually start with auth_makeauth as
  described above b) we would give a auth handle to an unknown person;
  sure, a user should not communicate with untrusted servers anyway, and
  the handle is not associates with any IDs, so probably that is not a
  serious issue.

So it seems we need to modify the auth interface, for example by adding
an "auth_prepare_authentication" RPC which will give us an object handle
that can't be used for *any* RPCs to auth.

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling  <address@hidden>  \\  http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\  http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["We're way ahead of you here. The Hurd has always been on the    ]
[ cutting edge of not being good for anything." -- Roland McGrath ]