Re: Clarification (was: Re: Challenge: Find potential use cases for non-trivial confinement

[Bas Wijnen]

On Fri, May 19, 2006 at 03:38:20PM +0200, Michal Suchanek wrote:
> >But a user session will not be confined, now will it?  It must be allowed
> >to communicate with the user, and the user must be allowed to communicate
> >with other parts of the system/world, otherwise the session is pretty
> >useless.
> 
> It depends. If you define communication with user as breaking
> confinement

I do.  The user is much worse than most other channels, because the user can
contact other parts of the system without even the kernel noticing (for
example by talking to other users, who will do things on their account).

> then no user session is never confined. Most user sessions
> will have many other capabilities as well. But some guest sessions can
> be very restricted. And it should be possible to create such sessions
> (ie when you install a system on an exhibition for demonstration
> purposes).

I agree that some sessions can be pretty limited, and of course that will be
possible.  I don't remember what the problem was now, so if it's still not
solved, please repeat it. :-)

> >> That way we only make the use of DRM software less secure (and
> >> priviledged because only an administrator can install it).
> >
> >No, an administrator could not install it.  Only the machine holder could,
> >and he would need to break his system for it.  Perhaps they will ask this
> >of people.  But I think this is the kind of limitation that they'll accept
> >as "what we want isn't technically possible on this system".  Since it's
> >not possible on other systems either, they will likely give up (just as
> >they do now) and resort to less effective means of protection, which do
> >allow reverse engineering, for example.
> 
> Since the administrator should not be able to observe user sessions
> the DRM software can be installed in a new user session. Problem
> solved.

I was assuming that you were talking about DRM software which protected itself
against all users on the system.  If the administrator installs it, then at
least the administrator himself can have access to it (because they can't
check that he did indeed give up his ability to log in to the session.  He
must have had it at first, because he had to install the DRM software).

Installing software which can be run but not studied by others is possible for
anyone, but they have to pay for it themselves.  If the administrator installs
it in a new session, then the system pays for it (the administrator has the
right to pay with the system's storage, so he did indeed pay himself).  That's
not something we even want to prevent.

Of course with opaque storage, any user can install such software in exactly
the same way.  And the installing user (administrator or not) can inspect and
debug it (although if opaque storage is the default this will be slightly
harder, it is still possible).

So in the end it comes down to:
- Without TC, remote parties cannot protect against reverse engineering.
- With opaque storage, users can install DRM software on their account which
  works (that is, others can pay for the storage and use the software without
  being able to reverse engineer it).
- Without opaque storage, they can still do this, but they have to pay for the
  storage themselves.

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