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

[Jonathan S. Shapiro]

On Thu, 2006-12-28 at 18:19 -0800, Jed Donnelley wrote:
> Finally, let me address this particular instance.  Firstly,
> I confess ignorance of the specifics of the implementation that
> the above paragraph applies to, so I may be misunderstanding
> something.  Accepting that possibility, however:
> 
> The above paragraph where "You (a client of the space) cannot
> read the capability in that slot, but you can traverse it"
> suggests a situation where a subject has a permission ("you
> can traverse it") but cannot share it ("You ... cannot read
> the capability).  This drops right back into mechanisms
> that prohibit capability communication (delegation in the
> most limited sense) - forcing something like a proxy
> mechanism for modular extension of services in accord
> with POLA and seeming to try to create illusions about
> blocking communicating conspirators.
> 
> To me any such mechanism is anathema.  I regard such mechanisms,
> in addition to being misleading, as working against modular
> extensions that are faithful to POLA.  I'm interested to hear
> others (e.g. Shap) defend such a mechanism.

Gladly.

The mechanism that I described is the foundational mechanism of virtual
address translation. In light of this, your position amounts to an
assertion that hardware-based memory protection is anathema.

Care to reconsider? :-)

The "traverse" right is conceptually equivalent to having a service S
that implements two facets A and B, will directly disclose some
capability to A, but will only wield it indirectly for B. The only
difference is that by reifying this right in the operational semantics
it becomes possible to do information flow analysis without analyzing
the code of S. We haven't exited the capability model at all here. It is
merely an optimization.

However, this optimization is important because it supports two other
things that we want: (1) it makes it possible for all mapping-related
metadata (i.e. page tables a.k.a. nodes) to be explicitly allocated,
which is necessary for proper storage accountability (2) it makes
possible the implementation of a particular form of encapsulation that
is essential to user-level pagers: the pager must provide a space to the
client, but for practical implementation it must be able to know that
the client cannot corrupt (i.e. alter) the metadata managed by the
pager.


shap