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

[Valerio Bellizzomi]

On 27/12/2006, at 1.47, Jonathan S. Shapiro wrote:

>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


How can we think about diminish-take ?


>
>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
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk