[cap-talk] Another "core" principle - Brinkmann

[Jonathan S. Shapiro]

On Sat, 2006-12-23 at 14:38 +0100, Marcus Brinkmann wrote:
> * My personal model of capabilities is stricter than yours.  For
>   example, I only allow capability delegation through authorized
>   channels, which exists in form of capabilities of course.  So,
>   whenever a capability is communicated from A to B, I need a
>   capability that is used for that.  Even if you think about
>   capability transfer in form of copying binary blobs of data...

But of course, binary blobs of data are only transmitted over authorized
channels as well.

Let me re-introduce some terms, because some readers may not have them:

   read  == read of data
   write == write of data
   take  == read of capability
   grant == write of capability

That is: there exist (at least) four primitive permissions that we would
like to distinguish. There exist systems in which these permissions are
in fact distinct (including KeyKOS/EROS -- Jed, what about DCCS?). There
also exist systems in which no permissions distinction can be made
between take/read and grant/write. No such distinction is possible
unless the implementation enforces some form of partitioning that
distinguishes capabilities from data. The partitioning can be
accomplished through hardware-based protection (tag bits), type safety
(object references are not just words), or software partitioning
(KeyKOS/EROS place data in pages and capabilities in nodes).

It is possible to preserve this partitioning between mutually trusting
run-times (i.e. kernels or vat implementations or such -- the layer that
implements capability call) by using data-only channels over a
cryptographically protected link. However, when people speak of
cryptographic capability systems, they generally do NOT have in mind a
system that preserves the data/capability partition for purposes of
communication permissions.

The "unmodified capability system" that Earl Boebert describes is one in
which read==take and write==grant. That is: one in which no partition is
enforced. Under this assumption, Earl's assertion that the *-property
(and confinement) cannot be enforced is correct.

My objection to Earl's paper doesn't lie with his conclusion. My
objection lies with the fact that the majority of operational or
conceived capability systems even at the time of his paper could not be
considered "unmodified capability systems" in the sense that he meant.


In any case, the behavioral distinction that Marcus raises between
cryptographic capability systems and OS/language capability systems is
an important one, and worth remembering.

shap