Re: Design principles and ethics

[Bas Wijnen]

On Sun, Apr 30, 2006 at 06:59:22PM -0400, Jonathan S. Shapiro wrote:
> > > So there is no /sbin/passwd, and it was not considered in the question,
> > > which about the program accessing a central password database (which I
> > > agree we should avoid if we can, but that is not the point).
> > 
> > A program that can access a central password database in write-mode is
> > _not_ confined.  It can be run as a system service that is accessed
> > through a capability, just like any other system service, if desired.
> 
> This is not correct. By executing the program the user is authorizing
> the program to access the password database. The requirement for
> confinement is that they be able to check in advance whether such an
> authorization is given.

In the case of trivial confinement, the child implicitly agrees for the parent
to debug it, because it allows to be started by it.  Let me put it
differently: The child's opinion about this is irrelevant, because the child
isn't a party in the operation of starting a confined process.  The parties
which are involved are the parent, which is the process starting the child,
and the instantiator, which is the process requesting the startup.

In order to guarantee confinement (and encapsulation, as you define it below),
A. The instantiator must know that there is no unauthorized outward
   communication.  Unauthorized by the instantiator, that is.
B. The parent must know that information cannot be extracted from the program
   without the parent's consent.

Now the question is: are these requirements fulfilled for the case of "trivial
confinement".  Indeed they are, because in that case the parent and the
instantiator are the same process, which leads to an implicit trust of each
other.
A is fulfilled, because outward communication can only occur through
capabilities which were given to the process by the parent.  Since the
instantiator is the parent, any capability it gives is by definition
authorized by the instantiator.
B doesn't seem to be fulfilled, because the instantiator has the right to
extract information from the program.  However, because the instantiator is
also the parent, this can only happen with consent of the parent.  Which means
B is fulfilled after all.

There's just one "but":  But what about the parent's parent?!
Well, that one is simple: Every child implicitly trusts its parent.  If it
doesn't, it must refuse to run at all.  The client runs on behalf of the
parent and gets all its rights (space bank, processor time, any communication
capabilities) from its parent.  Anything the client can do could have been
done directly by the parent.  There is no reason at all to protect against
this.

This doesn't mean that the parent's parent will always behave, of course.  But
this is not the client's (or the parent's) responsibility.  If the grandparent
misbehaves, he will have a good reason for this.  "The parent could have done
it without the child" is actually a recursive property, so the grandparent too
cannot gain priviledges (read: capabilities) from starting up a client and
spying on it.  But it can be used for debugging, which is a very useful
property. :-)

Jonathan: If after reading this you still don't agree that "trivial
confinement" is indeed confinement, then please tell me what is wrong with the
above proof.

> However, I realized this morning that I have made a mistake in my
> definition of confinement. I am mixing two things together:
> 
>   1. Confinement: program cannot communicate outward through
>      unauthorized channels. This is a restriction on "write out"
>      behavior.
> 
>   2. Encapsulation: information (including authority) cannot be
>      extracted from program without its consent. This is a restriction
>      on "read in" behavior.
> 
>      Since "encapsulation" is taken, this needs a better word.
> 
> I believe that Marcus is actually struggling with the second property,
> but I think that matters are a bit more subtle than this.
> 
> I am desperately trying to put a talk together for tomorrow, and I have
> not had time to think about this hard enough to be sure that I am being
> clear myself, but here is what I provisionally believe in the context of
> the confinement discussion:

Then in this case we (well, I at least ;-) ) forgive you for perhaps not
having read our responses very carefully.  But I agree with Marcus that it
starts to become a bit tiring to see that you "still don't understand it".  I
refuse to believe that you are incapable of understanding the things.  I will
continue trying to write as clear as I can, but I feel that with a bit more
effort from your side the discussion would be lot easier.

> In part, I *think* that Marcus and I are differing about encapsulation,
> but I am not entirely sure of this. Both DRM and password file write
> protection depend fundamentally on encapsulation -- this much is clear.

DRM depends on encapsulation + confinement, where parent != instantiator.
Password file write protection depends on encapsulation, but not confinement
(as you defined it above).

> From a purely technical perspective, there appears to be no difference
> here between the user authorizing access to the writable password
> database or the user authorizing access to the treacherous display.

The difference isn't in the authorization.  It's in the ability of the program
to verify that it is not debuggable.  The password program doesn't care if it
is being debugged, so it doesn't need this check.  The DRM application (which
runs on a server somewhere far away on the internet) does need it.  And it
even needs it remotely, which complicates matters a lot.

> In many respects it seems to me a good thing that something like the
> password database can be protected in this way; the weak link in
> passwords isn't cryptography. It is dictionaries. We do not want the
> password database disclosed to help the attacker, and for the same
> reason we DO want some control over appropriate selection of passwords.
> All of this is, in some sense, very DRM-like.

No, it isn't.  In case of a global database (for which passwords aren't a good
example, but let's assume a bit longer that they are), there actually is a
trusted entity, namely the TCB, which will handle it.  In case of DRM, the TCB
is not trusted unless it is certified and the certification is verified.

For a secure global password database, no non-trivial confinement is needed.
For verification of certification it isn't either, come to think of it.  The
TCB can simply contain servers which start DRM players on request.  They are
only debuggable by the TCB, which will not do that.  Providing this service as
part of the TCB is a choice which I'm sure the Hurd will not make, but that's
a different matter.

So tell me again, what do we need the constructor for at all (even morally
objectionable use cases are fine this time.  I can't think of any at the
moment...)?

> And this leads me to the following observation: it is a very drastic
> move to remove true confinement. It is probably much simpler simply to
> *decline* to support treacherous displays.

In fact, this isn't about "removing", but about "not adding".  The system
becomes simpler from it, not more complex.

> If half-blind holes are prohibited, DRM cannot be achieved, but even
> this may be too strong.
> 
> I am thinking that it may be possible to fix the set of half-blind holes
> at system design time. If this is done, and if the installer has
> insufficient authority to augment the set of half-blind holes, then I
> think that no third party can successfully install a DRM-capable player.

However, they can easily modify the system such that they can and certify that
instead (although GPL3 may get them in trouble in that case).

What are use cases for these half-blind holes?  I don't exactly understand
what they are, and we might not need any of them.

> So: would it be enough to remove the half-blind hole feature?

The question isn't if it's "enough".  If the constructor is unneeded, then
removing it simplifies the system, which is something with value of its own.

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