[cap-talk] - Bellizzomi - Capabilities and Shapiro's focus, Coyotos, etc.

[Jonathan S. Shapiro]

On Fri, 2006-12-01 at 01:38 +0100, Valerio Bellizzomi wrote:
> >> >I believe limiting shared resource is one of the objectives of Shap's
> >> >research (read the "Debunking Linus's Latest" and "From EROS to
> >> >Coyotos/BitC: Open Source meets Open Proofs" papers).
> >
> >This is true, though not because of any concern about covert channels.
> >One of the strengths of the KeyKOS design was that all metadata was
> >explicitly reified. Mapping structures, for example, are crafted from
> >Nodes. Nodes are named by capabilities, and the purchase of Nodes is an
> >accounted activity (via the space bank).
> >
> >This is in marked contrast to every other system I know about, where the
> >storage costs of metadata are assumed to be bundled up in the storage
> >costs of the data they map. The argument is usually that the mapping
> 
> Has this to do with placing the cost of resource allocation on the client
> and not on the server ?

Not really. There are really two problems here. The first is that the
log(n) argument is simply wrong, as I illustrated. The second is that in
the presence of sharing (not necessarily client/server -- can be peer
sharing) one needs to worry about resource denial.

> >> Please don't oversell capabilities and suggest that they can
> >> solve covert channel problems like wall banging.  I think it's enough
> >> to deal with overt communication channels as Jonathan suggests.
> >
> >I agree -- on both points.
> 
> I think we agree on this topic. It was never my intention to oversell
> capabilities, it was my intention to say that covert channel problems have
> been addressed in the sense that they have been discussed (at least) in
> this list, and that I have noticed some countermeasures in the ASPOS/PP.

Sorry. We are capability advocates. It is natural for us to advocate,
but because we are a minority camp we must take care to advocate
accurately. Occasionally I feel like I need to remind us (including
myself) of this. I think it was just that your statement had more than
one reading.

Concerning covert channels, the topic has been addressed in the more
useful sense that real work has been done on them. The problem, in my
opinion, is that there isn't a good handle on this area in the
literature. Two examples:

1. The literature still talks about storage and timing channels, though
later work showed that these are arbitrarily interconvertible and so
this is a completely false distinction.

2. The literature still refers to attacks involving observation of
metadata as storage channels.

In my view, the first indicates that we still haven't got a good
statement of the problem in the literature. The second tends to confirm
this, because in my view these observations aren't covert at all -- they
are actions enabled by the documented, deterministic behavior of
authorized operations on authorized interfaces. Obviously this is not
covert. More importantly, the class in (2) is subject to conventional
information flow analysis, while truly covert channels do not seem to
be. This suggests to me that class (2) is at best a distraction, and
that the confusion it introduces may be part of why we (as a field) are
struggling to get a handle on covert channels as problem statement.



shap