[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: confinement with endogenous verification ??
From: |
Brian Brunswick |
Subject: |
Re: confinement with endogenous verification ?? |
Date: |
Thu, 27 Oct 2005 12:35:56 +0100 |
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
- confinement with endogenous verification ??, Brian Brunswick, 2005/10/26
- Re: confinement with endogenous verification ??, Jonathan S. Shapiro, 2005/10/26
- Re: confinement with endogenous verification ??, Brian Brunswick, 2005/10/26
- Re: confinement with endogenous verification ??, Jonathan S. Shapiro, 2005/10/26
- Re: confinement with endogenous verification ??,
Brian Brunswick <=
- Re: confinement with endogenous verification ??, Bas Wijnen, 2005/10/27
- Re: confinement with endogenous verification ??, Jonathan S. Shapiro, 2005/10/27
- Re: confinement with endogenous verification ??, Brian Brunswick, 2005/10/27
- Re: confinement with endogenous verification ??, Jonathan S. Shapiro, 2005/10/27