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

[Valerio Bellizzomi]

On 01/12/2006, at 11.33, Jonathan S. Shapiro wrote:

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

>From the standpoint of resource denial I say that:
1. For client/server, the client pays for resource allocation,
2. For peer sharing, both peers are client+server, so each peer pays for
its own resource allocation.
Is this sound ?

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

Don't worry :-)

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

In
http://chacs.nrl.navy.mil/publications/CHACS/1994/1994landwehr-acmcs.pdf
(pages 4,5,6), covert channels in both storage and timings are classified
as "intentional, nonmalicious", which are introduced in design or
implementation. They also say that covert channels can be in scheduling,
identification/authentication, and also in hardware.

By the way, Lampson is referenced in their definition of covert channels
in page 7, section 2.1.2, where they also say "The distinction between
storage and timing channels is not sharp. Exploitation of either kind of
channel requires some degree of synchronization between the sender and
receiver. It also requires the ability to modulate the behavior of some
shared resource...".

This could be a starting point.

>
>
>
>shap
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk