Re: Confinement (even with TPMs) and DRM are not mutually exclusive

[Eric Northup]

On Tue, 2006-06-06 at 14:37, Marcus Brinkmann wrote:
> At Tue, 6 Jun 2006 11:13:55 -0400,
> Eric Northup <address@hidden> wrote:
> > I have been very concerned to see the discussions leaning towards
> > abandoning the security benefits associated with the design patterns
> > from KeyKOS and its descendants.
> 
> It may be well worth being explicit about the "security benefits" you
> refer to.  Some apparent "benefits" may (at least by me) be considered
> harmful and a security threat.

I think it is desirable for the system model to be able to *express*
scenarios like DRM, because this means we have a very general language
for describing security policies (as implemented by programs/object).

However, just because it can be expressed does not mean it should be
supported.

>   Of course, being explicit about it may
> very well throw us back into the beginning of the discussion.  OTOH,
> leaving out the specifics leaves it up for interpretation, which leads
> to confusion.
> 
> > I think there may be a design which supports both goals.
> 
> The design you describe basically is: Use Coyotos, but give the user
> more options to configure which program has access to which resources.
> Well, I would hope that Coyotos already gives users such options.
> 
> Presumably, programs will be able to detect what they get from the
> user, so they can simply deny service.

I forgot to describe the most important part of the design (d'oh!).

The point was to tightly restrict how programs can detect what they get
from the user.  In particular, it would *not* be possible for programs to
detect the difference between a direct connection to the sound device,
and a connection to an intermediary which logs and dumps all the audio.

There are some services which ordinary programs should be able to
authenticate (I gave a partial list earlier).

>   A practical consequence is
> that the user stops using the options, because they break the programs
> that the user is expecting to work.  [...]

Exactly.  That's why the system should not* provide a way to authenticate
the low-level services which might be (ab)used to implement freedom-
restricting DRM policies.

*It might be desirable for some very trusted parts of the system to be
able to authenticate such services.  But such abilities could be
represented by closely-held capabilities, which are not available to
users.  Until a compelling use case arises, it's probably safest to not
make such authentication available at all.

Sorry for the confusing way I've presented this design.

-Eric