Re: confinement with endogenous verification ??

[Jonathan S. Shapiro]

On Thu, 2005-10-27 at 16:50 +0100, Brian Brunswick wrote:
> 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.

Yes, but actually it is more restricted than that. There are things in
the TCB that are not in the kernel. The "read only" property can only be
enforced for kernel-implemented objects.

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

Yes, and the problem is that the kernel has absolutely no way to detect
and prevent this, because it has no ability to see the semantics of the
server code.

This is part of why confinement is important. It usually eliminates the
need to know whether a server is read-only, because the server has no
way to make any significant leaks.

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

I am somewhat concerned about this as well. Unfortunately, people have
been trying to close covert channels for 30+ years with very very
limited success. I think that we need to apply what is known about this
(especially because it tends to improve system performance anyway), but
we should not delay for a perfect solution. Unlike the problem of
containing hostile code, restricting covert channels completely is
something that we simply do not know how to do -- not even in the
research literature.

shap