Re: Part 2: System Structure

[Bas Wijnen]

On Mon, May 15, 2006 at 04:49:35PM +0200, Pierre THIERRY wrote:
> > 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.

Correct.  I haven't seen a definition of DRM anywhere, so I just used the
words.  It may be a bit confusing, though, sorry about that.  Anyway, like
Marcus I don't really care what it's called, as long as we all know what we
mean.  Eh...  So we shouldn't call it DRM then. ;-)

> > 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?

The difference would be that only user-approved processes could use it.  With
the constructor, any process can use it.

> 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.

As far as I know, storage is the only resource for which the opacity property
makes any sense.  Am I missing something?

> 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).

Yes, that was the idea.  It's fully implemented in the session.

> > 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.

It depends on what you call transparent.  With the constructor as Jonathan
wants it, _every_ subprocess receives such an opaque donation of its storage.
While it is transparent in the sense that the user knows about it, it doesn't
actually give the user any choice.

> In fact, your proposal forgets POLA.

Why?

> 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.

No, that's not how it works.  The constructor only accepts opaque storage.  So
if the user wants to use a constructor, she _must_ give opaque storage, or the
constructor will refuse to use it.

> It this sense, I think the constructor satisfies the Awareness and
> Security requirements of the Hurd,

The constructor satisfies Awareness by removing the choice and assuming that
the user is aware of the default.  Doesn't sound good to me.  Especially
because the default is not what we want in most cases.

> whereas the specific storage for opaque donation breaks Flexibility, because
> you cannot donate any part of your storage as you want. Check ;-)

Programs cannot, but the user can.  Which is good.  Programs cannot give up
the freedom of the user to look at his own programs, unless the user
explicitly gives them permission to do this.

> 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.

Ok, I was assuming that already, but thought you had some extra security in
mind. :-)

> > > 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...

Of course.  They shouldn't be allowed to change previous entries, only add new
ones.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature