Re: confinement with endogenous verification ??

[Brian Brunswick]

On 27/10/05, Jonathan S. Shapiro <address@hidden> wrote:
> On Thu, 2005-10-27 at 12:35 +0100, Brian Brunswick wrote:
> > 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.
>
> All of the capabilities that are considered transitively read only name
> object types that are implemented by the kernel, so yes, the system
> enforces this constraint. As I said earlier, endpoint capabilities do
> not satisfy this test.
>
>
> An endpoint capability is the one you need to send a message (i.e.
> perform an IPC) to a process.
>

Ah ok. So there is a distinction between capabilities backed by the
system/TCB, and ones backed by other processes. The "read only"
property is only allowed for (certain) things in the TCB.

> >
> > How are "read-only" capability restrictions enforced for this?
>
> I do not understand the question. The sources of covert channels have to
> do with the internal multiplexing decisions of the operating system.
> Read-only restrictions on capabilities are concerned only with *overt*
> actions.

I was imagining that read-only capabilities might be implemented by
random servers - then of course they could simply rename a write call
into a read one and communicate.

> > 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)
>
> Not quite. Confinement is confinement of *overt* communication (either
> data or capabilities). The reason that capabilities can be covertly
> confined is that the program attempting to transmit never holds the
> capability in the first place, and there is no operation by which a
> receiver can fabricate a capability out of thin air.
>
> Note that cryptographic capability systems (and all other unprotected
> capability systems) *are* vulnerable to capability leakage, because
> capabilities are just data in such systems. This is why I said that
> capability confinement could only be achieved in protected capability
> systems.
>

Yes. That point should be emphasized. I guess its probably /the/ most
important consideration in the choice between cryptographic and
protected capability systems.

Musing further... capability confinement is an alternative to revoking
capabilities. We've given a capability to an untrusted piece of code,
and want to clean things up when its done its job. We can either keep
the capability live, destroy the untrusted subsystem (when sure
nothing can have leaked), or instead revoke the capability, so its no
more use even if it has leaked. Hmm...

I still worry about covert channels in even read-only access. If
something could observe the pattern of what's read..... Its not a
panacea, still needs judicious use.

--
address@hidden