Re: confinement with endogenous verification ??

[Bas Wijnen]

On Thu, Oct 27, 2005 at 12:35:56PM +0100, Brian Brunswick wrote:
> > Can you explain where you think the escalation is happening? The
> > constructor does not have special privilege because of any escalation.
> > All of its privilege derives directly from the capabilities that it
> > holds. The constructor does not have any special privilege beyond what
> > it's capabilities permit.
> 
> But its constructing something that has those special capabilities, on
> the demand of a client that doens't. So the client is getting some
> sort of service done for it with escalated priviledge... Exactly what
> setuid does. (only more secure we hope)

The constructor works not only on request of the client, it has two other
masters (well, only one master really):
- the meta-constructor defines that the constructor will do its job correctly.
  In particular this means that the confinement check works (the constructor
  doesn't lie about this).
- the process which built the constructor (using the meta-constructor) is
  allowing others (which hold a capability to it) to create processes with it.
  This process may have put in its own capabilities, and in this case it did
  (because the requestor doesn't have the capabilities that the resulting
  program needs).

So it's not escalation, the process simply gets its capabilities from more
than one source.

> >  2. Capabilities cannot be leaked over covert channels. They can be
> >     proxied, but once the program that holds the capability is killed
> >     you know that the access is terminated.
> 
> Yes, that has to be a big benefit. So read-only may just apply to
> capability transfer. Indeed, perhaps thats enough...

No, we should try to eliminate the covert channels as well.  We just may not
succeed.

> >  3. Covert channels do not allow theft of information. They only allow
> >     *disclosure* of information. English: we don't need to solve the
> >     covert channel problem in order to solve the virus and hostile
> >     plugin problem.
> 
> Hmm.... not sure this is a useful distinction in the presence of
> buffer overflows and other similar bugs. Disclosure may be prompted
> too easily....

What it means is that you need a capability to the information in order to
steal it.  If you crack my web server because it has a bug, then covert
channels aren't going to help you getting access to my private files, because
none of my programs with access to them (which have not been compromised) are
going to send them over the covert channel.  So covert channels can disclose
information that the compromised program has access to when that's not
supposed to be possible, but it isn't allowed to steal it when it doesn't have
the access.

> > Because of covert channels, confinement of *data* is not absolutely
> > possible. Confinement of authority (capabilities) *is* possible. This is
> > why I feel that the primary advantage of confinement as the standard
> > tool for process instantiation is its effect on system structure and
> > developer habits.
> 
> Ah ok. So confinement is confinement of capabilites. Which in a
> persistent system is really, really important. (And not much less in a
> non-p system)

And for practical purposes I expect it is mostly true for data as well.  I'm
saying here that I think we can eliminate most covert channels, or at least
the high-density ones.

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