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

[Valerio Bellizzomi]

On 28/12/2006, at 1.32, Valerio Bellizzomi wrote:

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

If this is not clear, I am reposting to expand: 

1. What is the general correspondence of diminish-take in the terms above
?

2. Is diminish-take an operation that weakens a write access to a read
access in the taken 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
>>
>>_______________________________________________
>>cap-talk mailing list
>>cap-talk at mail.eros-os.org
>>http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk