Re: Part 2: System Structure

[Pierre THIERRY]

Scribit Bas Wijnen dies 15/05/2006 hora 14:15:
> Well, maybe the problem isn't as big as it seems to me, but what I see
> as the problem isn't that it can't be done, but that there're so many
> developers who all need to be convinced that this is the way to do it.

Sure, as long as game programmers don't adapt a little their program to
split the game itself from the high score update service, the bug could
appear easily. But that's no difference with the current situation.

So there will be an easy way to strengthen reliability, and no loss.

> For digital rights management: - You have the right to read the data,
> and do what you want with it.  - You have the right to write the data
> through the game program.

You're playing with words here. If you define DRM so broadly, then any
access restriction system is DRM. And current Linux and Hurd are already
DRM.

> If this case does show a need for opaque storage donation though,
> there is a solution (for this case):  The user session can provide a
> service which reserves a piece of storage.  It can guarantee that only
> the requestor gets a capability for using it (although the session
> will keep one for itself, to destroy it on user request).  The user
> can then provide the game service a capability to its session.

What would be the very difference with adding the constructor pattern?
In fact, you seem to suggest to add constructor to the Hurd, but only
allowing opacity of resource donation on specific parts of the
resources.

Which could be a way to add the constructor to the Hurd while not
modyfing Hurd itself, I think (i.e. not touching it's space bank
service, and adding another one, in parallel).

> Note that this is possible only because the user session is part of
> the TCB.  Also note that this is a very special situation.  The user
> will not usually give this capability to anyone, and so "normal"
> programs are not able to use such services on their own: they need the
> user's explicit permission (in the form of the capability).

I did not understand that with the constructor, the opaque donation
would be transparent for the user. In fact, your proposal forgets POLA.
The constructor has no right to opcacify a resource donated by the user.
It has to ask the user for the authority to do it. So the user would
never make opaque donation without knowing what he is doing.

It this sense, I think the constructor satisfies the Awareness and
Security requirements of the Hurd, whereas the specific storage for
opaque donation breaks Flexibility, because you cannot donate any part
of your storage as you want. Check ;-)

> > Sure. For things like ping or traceroute, a Hurd-NG will be far more
> > simple and secure.
> Huh?  I wouldn't expect that it makes a big difference.  Why would it
> be any simpler or more secure (except that they don't have access to
> the rest of the system)?

Unix ping breaks POLA, because the ping binary, when started, has
unrestricted access to the TCP/IP stack, IIUC. It is trusted to only use
it to send specific ICMP messages, but in the advent of a bug or a
compromission of ping, it could be used to gain full access the the
stack, and send whatever one wants.

A POLA ping would only have a capability to a specific ICMP sending
service. That's very similar to the confused deputy problem and
solution.

> > What if the administrator wants to enforce some policy about what
> > can update utmp, though? I think we fall back to the previous use
> > case.
> I suppose so.  Although I don't see why an administrator would want
> that.

Maybe there's a reason why utmp is not fully writable by users...

Doubtfully,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature