[cap-talk] More Heresey: ACLs not inherently bad

[Bill Frantz]

shap at eros-os.com (Jonathan S. Shapiro) on Thursday, September 18, 2008 wrote:

> Any particular definition of what might constitute a consistent set
>  of access rules, though it is presumed that such a notion will exist
>  in any particular use case.
>
>  Any policy concerning who is authorized to revise which parts of the
>  permissions, though it is assumed that such a policy will exist in
>  any particular use case. It is further assumed in this challenge
>  question that the task at hand requires that
>
>    - All users (clients) appear to traverse identically the same
>      capability graph at all times, sharing a consistent view of
>      the graph, 
>
>    - The task includes operations that alter the graph structure,
>      as distinct from merely adding/removing/modifying the leaf
>      objects. This is important because it reveals why replication and
>      membrane strategies are probably unsatisfactory here in OS-based
>      capability systems.
>
>      Since the task imposes these requirements, it should be understood
>      that we are focused on policies that both permit and selectively
>      authorize such *general* graph updates, as opposed to just leaf
>      revisions.
>
>  Any particular mechanism by which authorities are specified, recorded,
>  or enforced. However:
>
>    - It is assumed that suitable mechanisms must exist in any real
>      implementation.
>
>    - Any particular choice of mechanism whose performance or storage
>      requirements are prohibitive would of course be rejected.
>
>    - Any particular mechanism in which revoking access by one party
>      causes access by a second party to be lost fails the
>      requirements.
>
>And I would add, based on a round of discussions a year or so ago, that
>if the implementation is unable to determine when reclaiming an internal
>data structure might break something, the solution must be rejected,
>because inability to reclaim constitutes a priori evidence that the
>storage requirements are not boundable and therefore prohibitive.

One reason I haven't chimed in is that this discussion is far too
abstract to engage my mind. I think my approach is fairly general,
but I really have trouble thinking in the abstract without a
specific example to reason from. Anyway, here goes:


I would approach this set of requirements building the graph
structure out of opaque elements. In and of themselves, these
elements convey no significant authority (however, see below).

Each user of the graph has one (or more) rights amplification
objects. These objects accept an opaque object and return a
"useful" object, subject to the security policy. These objects play
a role somewhat like groups in Unix.

The style of use is to pass the opaque objects to other users, and
only use the useful objects for direct use. Think of the useful
objects as playing the role of the result of an "open" operation.
This way no user gets more access than implied by the amplification
objects held.

It might be argued that this design does not prevent users from
sharing the useful objects, to which I would reply that they can
also proxy, and that one voluntary oblivious compliance system is
much like another with regard to policy enforcement.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032