Re: Where should port rights go?

[Farid Hajji]

> > > Many ways to implement port rights come to mind. Here are some ideas:
> > <snip>
> > 
> > 9. port-rights entirely managed by concerned parties:
> > 
> >    * every communicating party is uniquely identified by its
> >      sender-id/receiver-id. This information is provided by
> >      the kernel/libmom and is considered trusted.
> >
> > [...]
> >
> >    - slight chance of forgeability by clients that poll every random-id
> >      from a server (guessing id's).
> 
> If you check (and trust) the sender ID of a message, how can an
> untrusted client (whos sender ID doesn't match any trusted ones) to
> find a way in?  Is it possible (in L4) to forge the sender ID in a
> message?
Consider the following scenario:

   1. client C1 requests a port-right from server S
   2. server S generates a random-id r, saves it in
      an internal [multi]map (<C1,r>) and sends this random-id
      to C1.
   3. C1 transmits this port-right to C2
      (e.g.: perhaps C2 is going to become a child of C1?)
   4. C2 sends <C2,r> to S.

      Now you get two alternatives:

   5. S rejects r, because <C2,r> is not in S's map, only <C1,r>
  5'. S accepts r, because <*,r> is in S's map.

+ 5  would be secure and no forgeablility can occur, because Sender-ID
     C1/C2/Unknown would be passed by L4 to S and that is trusted.
- 5  inflexible, because port-rights sent to a client cannot be delegated
     to other clients (but see below)

+ 5' is flexible, because port-rights can be delegated to other clients,
     without involving the originator S of the port-right.
- 5' any other untrusted party, CU could poll S by sending <CU,x> messages
     to S. As soon as <CU,r> is received by S, the port-right would be
     wrongly acknowledged.

5 is of course the only secure (distrbuted) mechanism for managing
port-rights without risks of forgeability. To enable C1 to delegate
a port-right to C2, C1 should send a notification to the originator
of the port-right (S):

  6. C1 wants to _move_ 'r' to C2:
       * C1 sends to S a notification: <C1,move,C2,r>
       * If S allowed the move, it would remove <C1,r> from its map
         and insert <C2,r> instead (effectively transferring the right
         to C2).
  7. C1 wants to _copy_ 'r' to C2:
       * C1 sends to S a notification: <C1,copy,C2,r>
       * If S allowed the move, it would insert <C2,r> in addition to
         <C1,r> to its map.

This mechanism is possible, if S trusts C1 to transfer port-rights
correctly. I see no forgeability issue here.

Using this distributed mechanism would relieve us from the IPC bottleneck
of a central port-rights server, but we need to:
  a. define a protocol for sending,receiving,moving,copying ... port-rights.
  b. consider notification mechanism about recycled sender-id(s):

About b.:
  * Because L4 tasks are only limited in number, they have to be recycled.
    This could affect the L4 sender-id(s), right? A new task could use
    an old sender-id that is still registered in a map of some originator
    of a port-right. [Question: What about version-ids? Are they part of
    sender-id in L4? If yes, are they guaranteed to remain unique?]

  * old port-rights needs to be revoked, if a sender-id is recycled.
    This must be done through some notification message to the originator
    of a port-right. Two problems here:

      x Who would notify the port-right maintainers? Probably 'proc' server
        on exit() of a Hurd process.
        -> This requires that the port-rights maintainers register with
           proc, when they give out a port-right to a client (for the
           first time only). (*)

      x Many port-rights originators would need to be notified separately.
        'proc' could use the information gathered in (*) to notify each
        one of them.
        -> 'proc' could become the IPC bottleneck on process exit.

Implementing this scheme could be done in a library that would need to
be linked against every Hurd binary. This library would dedicate a thread
to handle the port-rights protocol and associated port-rights map of every
client, as well as registering with 'proc' (or whoever). A binary not
linking this library could simply not participate in the port-rights
passing scheme unless it does this stuff manually.

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.