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

[Bas Wijnen]

On Wed, Jun 07, 2006 at 01:27:52AM -0400, Jonathan S. Shapiro wrote:
> On Tue, 2006-06-06 at 23:13 +0200, Bas Wijnen wrote:
> > On Tue, Jun 06, 2006 at 11:13:55AM -0400, Eric Northup 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.
> > 
> > The security you speak of, as far as I understand (but I agree with Marcus
> > it's better to be specific, so I will be) is the security of programs
> > against users owning them (where owning means the program received all its
> > capabilities and the initial code image from that user).  This will never
> > work.
> 
> From a purely technical perspective, this statement appears (to me) to
> be wrong. It is very clearly possible to technically achieve DRM.

You might be talking about multi-user (or system+user) situations.  Also, I
was completely disregarding TC (since TC is implemented by the system,
anything concerning both TC and a user is a system+user situation).  I was
speaking only of a single-user scenario, where the user has the code and makes
it execute somehow.  The user is in complete control.  If even in that case
she isn't, the sytem is not useful enough for me.

> > The sole reason this program exists is the user.  It shouldn't have
> > protection against her.
> 
> This is an example of "post hoc, propter hoc" reasoning. You are
> reasoning backwards from conclusions. The conclusion (a value judgment)
> is that "the sole reason the program exists is the user". This
> conclusion is highly questionable.

No, that's not a conclusion.  It's an axiom.  Axioms are not questionable. ;-)
If the axiom doesn't apply to a certain situation, then the conclusions are
meaningless in that case.  I'm saying that in any sensible single-user
situation, the user is in complete control, and the axiom does indeed apply.

> If you would qualify this by saying "In the architectural/design
> philosophy of the Hurd, the sole reason that a program exists is to
> server its user" then I have no objection to the statement.

I would rephrase this as "In the Hurd, all single-user situations are
sensible, and therefore the axiom applies to them".

> I simply want it to be clear that this is a declaration of philosophy with
> technical implications, and should not be confused with a statement of
> technical fact or feasibility.

Of course it is possible to create a system where single-user situations may
not be sensible.  You seem to want that.  I fully agree that it is technically
possible for the system to intervene when it shouldn't (IMO).

> > So the user knows if the device is "direct".  The program doesn't need to
> > know.
> 
> Um. No. Anybody who has looked at the trusted path issues in electronic
> voting can explain at great length that it is *extremely* difficult for
> either the user or the computer to know this, and that all currently
> feasible mechanisms for this rely on some form of very carefully
> implemented DRM that permits end-to-end authentication of a closed
> device at the user end.

This surprises me.  If the system holds a capability to the keyboard, and
passes it to one user session at a time, revoking it again at logout, why is
it hard to keep track of it?  I would think that in that case, the user
session can very easily control who has access to the capability and who
doesn't, and thereby control when it is exclusively held by itself (and some
trusted system parts which don't do anything with it).

Do you perhaps have some pointers to reading material?

> What you assume here certainly isn't as simple as you make it, and is
> actually false in the absence of extremely careful design (that does not
> exist in *any* current commodity product).

Well, yes, I'm assuming a protected capability system with a TCB which is
designed to allow the session to guarantee exclusivity.  But while that is
indeed not present in any commodity product, I don't see anything new with
respect to the systems we're discussing here (both Coyotos and the Hurd as
proposed).

> > >       -Some devices may offer limited guarantees of exclusivity.  For
> > >        example, that while printing a contract, no other program can
> > >        insert the word "not".
> > 
> > I'd say that invoking a capability to a printer should send a whole
> > document, not only a part.  No need for exclusivity in that case.
> 
> What you describe is technically referred to as "exclusivity".

Is it?  I'd call it an "atomic operation".  Exclusivity means noone can do
things with it while I'm using it.  Atomic operations don't cost zero time, so
you're right that it could be called exclusivity.  But there's no need for
special locking (which I do expect when talking about exclusivity), the server
will simply be busy while handling the request.

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