Re: Design principles and ethics

[Jonathan S. Shapiro]

On Sun, 2006-04-30 at 22:40 +0200, Marcus Brinkmann wrote:
> At Sun, 30 Apr 2006 22:03:41 +0200,
> Pierre THIERRY <address@hidden> 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.


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:


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.
The reason that we do not object to /sbin/passwd in a UNIX-like system
is that the encapsulation is not absolute (root can bypass it). The DRM
problem in capability systems is that the encapsulation *may* be
absolute in practical terms (i.e. requires disk forensics, and may be
truly impossible given a TCPA chip and an OS that encrypts the disk).

But encapsulation alone is not enough to support DRM. The *real*
complication here is that a user can *authorize* capabilities that they
do not *possess*. This creates an interesting issue:

  1. Even if the program is fully encapsulated, DRM does not occur
     unless the user authorizes the program to disclose bits to a
     treacherous (non-recordable) display.

  2. The DRM agent cannot accept a treacherous display from the user
     unless it has independent means to authenticate that this is,
     in fact, an authentically treacherous display (otherwise the user
     could proxy the display capability; the DRM software must guard
     against this).

  3. The DRM agent therefore cannot trust the user as the source of
     the authentication method for the treacherous display capability.

  4. This means that DRM cannot be accomplished in the "confinement
     without authorized holes" scenario. It requires authorized holes,
     because the authentication capability is a hole.

  5. This implies that if we *wanted* to support DRM, then it is
     necessary to have some means for the user to perform this type
     of "half-blind" authorization.

     I say "half-blind" because we could design this in such a way that
      (a) the user can inspect to determine what they are actually
          authorizing, but
      (b) the ability to make this query does not give the user
          direct access to that authority.

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

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.

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.

I observe that in KeyKOS there were exceptionally few examples of
programs that actually *used* this half-blind authorization mechanism --
in practice, all of the programs where you might initially believe this
was useful were well-known programs (like the password changer) that
were not really *expected* to be confined, or could be redesigned to
avoid confinement (though with added complexity). For patent reasons
(now expired), the EROS constructor did not actually implement the
half-blind mechanism at all.

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


shap