[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where should port rights go?
Re: Where should port rights go?
Sun, 26 Nov 2000 04:58:33 +0100
> > > 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
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
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
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
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):
* 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.
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.