[cap-talk] Selling capabilities programming

[Marcus Brinkmann]

At Wed, 25 Jul 2007 09:12:27 -0400,
Sandro Magi <smagi at higherlogics.com> wrote:
> 
> Marcus Brinkmann wrote:
> >> Most access control work is concerned with overt channels, but covert
> >> communication is still a problem, particularly when powerful authorities
> >> are controlled by a mere 128-bits; proxying over low-bandwidth covert
> >> channels is much harder than transmitting a 128-bit data capability.
> > 
> > When a covert channel between a confined program and a non-confined
> > program becomes your most likely (or even one likely) attack scenario,
> > you must have first done all other things right.  In particular, most
> > systems have extremely high bandwidth covert channels for all we know.
> > Therefore it seems to me that the practical relevance of this argument
> > is close to zero.  In actual implementations and real world
> > applications, other problems are much more pressing.  Every attacker
> > will of course be happy for every minute you spend on Hollywood
> > scenarios instead of fixing bugs and maintaining installations.
> > 
> > You don't say what the 128 bits are used for.  If it is a session key
> > it is only valid for a limited segment of the transfered information
> > (for example, maximum one hour in a default SSH configuration on
> > todays system).  If you keep your private key on a smart card it can
> > not be read out remotely, covert channels or not (the smart card
> > implements the confinement property in hardware).  That's affordable
> > security which works today across all systems.
> 
> The 128-bits are the data representation of a capability in a
> capability-as-data system (CAD), ie. it is necessary and sufficient to
> present those 128 bits to access a resource.
>
> 128-bits is so trivial to transmit, that any local capability system
> implementing CAD might as well have no security at all.

But the premise was that there are two cooperating processes, one of
which has a legitimate copy of the capability already and could just
as well proxy.  So there are (at least) two cases where capability
leakage over unauthorized channels can harm you:

1. The covert channel bandwidth is large enough for capabilities, but
not large enough for a proxy.  As I said in my previous mail, I am not
very interested in such systems, although they surely exist.

OR

2. The capability is durable and survives the life-time of the leaking
process significantly.  This is the copy vs map (revocable copy)
discussion or membrane discussion all over again.  Should capability
delegation be revocable by default or not?  This is a deep problem
with good arguments on either side.  You say:

> Making the data capability "non-durable" recovers some usefulness from
> such systems, but the complexity inherent to such an approach seems
> insurmountable to me at the moment.

This is not at all obvious to me.  I would like to hear about use
cases where you believe an application (ie, not the shell) requires
durable capability delegation.  I have spent quite some time
investigating this question, but did not come to any definite
conclusion, and the capability community seems to go back and forth on
this one.  Maybe there is no uniform answer.

I admit that if the answer is that it is important to allow for
non-revocable copy to rather confined programs, there is a significant
difference between capabilities as data and protected capability
systems.  I am saying "rather" confined because I mean processes which
do not already have legitimate broad authority to distribute the
capability.  I am talking about the movie player, not the shell.

Thanks,
Marcus