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

[Bas Wijnen]

On Thu, May 04, 2006 at 02:08:36AM -0700, Michal Suchanek wrote:
> Since the administrator has the authority to give space to the
> instantiated user session, and the authorty to revoke it yet he is not
> allowed to look at the space it is pretty much the same as if the
> session was running on his space with encapsulation.

Yes.  The administrator has the authority to give space to the user's session,
but it's _not his own space_.  That's the big difference.  If I (as a user)
set up a server which lets clients start programs, then I do so on my own
space.  I can look at it, my client can't.  In this case, the TCB offers such
a service to the administrator.

> A browser plugin will want to communicate with the user as well. Does
> that mean that we cannot have a confined browser plugin?

Sort of.  It means that if we want a confined browser plugin, it must be
started by the shell, not the browser.  The browser can tell the shell that it
wants this and the shell can then do it (or not, to avoid pop-up style
behaviour).

The user should only type sensitive data into an application which is trusted
to handle it.  There may be cases that the plugin is trusted enough, but the
browser isn't.  In such cases the plugin should be started by the shell, not
by the browser.  This is the case anyway if there should be communication,
because the shell cannot reasonably check if the browser isn't tapping the
connection (technically it can, because it owns the browser, but it isn't
realistic to expect such checks to happen, I think).

> And you probably will want to decide what capabilities a new user session
> has, and create even very restricted (ie guest) sessions.

Yes.  Do you see any problems with that when it is implemented as a trusted
service?

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