Re: confinement with endogenous verification ??

[Brian Brunswick]

On 27/10/05, Jonathan S. Shapiro <address@hidden> wrote:
> On Thu, 2005-10-27 at 02:00 +0100, Brian Brunswick wrote:
> >
> > So is this confinement in some sense relative to assumptions about
> > additional access? The program could then give the subsystem
> > additional capabilities and change that? But nothing else can because
> > it hasn't the capabilities to the new subsystem? (/Can/ capabilties be
> > sent over IPC channels in EROS, or only at creation time?)
>
> I am not entirely sure that I understand the question, but let me
> attempt an answer and we will see how close we get.
>
> The test performed by the constructor establishes an initial condition.
> It guarantees that the initial capabilities held by the new process
> divide exactly into two sets:
>
>   1. Capabilities that are transitively read-only. These are harmless.

Ah yes... I meant relative to this definition of "read-only"
capabilities. Does the system somehow enforce that the implementation
of a read-only capability can't save any data, or isn't that
immediately a big channel where data can leak.

> Yes, capabilities can be transmitted via IPC. However, an endpoint
> capability is NOT considered to be transitively read only [exception: a

Ah, thats another question I was going to ask. Can you clarify the
meaning of "endpoint capability" please?

> This is a surprisingly effective barrier, because it makes natural human
> laziness an ally rather than a source of vulnerability. In consequence,
> it tends to lead to systems that default to safe configurations rather
> than unsafe configurations.

Absolutely!!

> 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)

>
> Secrets are not directly relevant to confinement. Confinement is a
> constraint on outward communication.
>
> Yes, if you are concerned about covert channels, then you get into
> real-time issues, and scheduling of multiplexing, and a long list of
> other challenges. These do not have general solutions, which is very
> troubling. There *is* some good news:
>
>  1. The sources of covert channels can be reduced without altering
>     the program.

How are "read-only" capability restrictions enforced for this?

>
>  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...

>
>  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....

>
> 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)

--
address@hidden