[cap-talk] Selling capabilities programming

[Marcus Brinkmann]

At Tue, 24 Jul 2007 23:02:06 -0400,
Sandro Magi <smagi at higherlogics.com> wrote:
> There are indeed user-observable security properties between CAD and
> protected capabilities (PR) in the *local* case: shared secrets can be
> leaked very easily locally over covert channels, whereas protected
> capabilities can only be proxied; this has been discussed extensively
> here in the past, so an archive search is prudent.
>
> 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.

Of course you might see things differently if your funding comes from
the military or other agencies.  But personally, I wouldn't lose any
sleep over covert channels, and so would most other people, I guess.

Thanks,
Marcus