[cap-talk] More Heresey: ACLs not inherently bad
Charles Landau
clandau at macslab.com
Thu Sep 18 10:52:15 CDT 2008
Jonathan S. Shapiro wrote:
> Please go back and re-read my original problem statement. If it was not
> clear, please say what needs refinement.
> On Wed, 2008-09-17 at 19:28 -0700, Charles Landau wrote:
>> On 9/12 at 9:06 pm Jonathan S. Shapiro wrote:
>>> Problem:
>>>
>>> Alice, Bob, Henry, Elmo, Oscar, and so forth are involved in a task
>>> that requires that all of them manipulate and modify some object
>>> graph. By "manipulate and modify", I do not mean merely that they
>>> modify the leaves of the graph. I mean also that they modify the
>>> structure of the graph itself. It is required that the parties be
>>> able to have different access rights on different subgraphs.
>> Some thirty messages later, I still don't have clarity on who gets to
>> decide who has access to what.
>
> It doesn't matter to the problem at hand. There is a party who decides.
> For this example, we can call them "God". :-)
I think it does matter. Suppose that "God" decides that Alice should
have access to object L, while Bob should not. Further suppose Alice and
Bob can communicate, and Alice wishes to proxy L to Bob. This is a
problem that neither capabilities nor ACLs can solve.
> The challenge problem does
> posit that the permissions may change. It does not specify mechanism for
> that change.
I take you to mean, the challenge problem does not specify a *policy*
for changing permissions.
Since capabilities are all about controlling permissions, and you are
not specifying the requirement for that, perhaps this list is not the
appropriate venue for this discussion.
>> For example, if Oscar has read-only access to leaf object L, and stores
>> a reference to L in node/directory D, to which Henry also has access, is
>> it possible that Henry could thereby acquire write access to L? In other
>> words, can Oscar grant more authority than he himself has? If so, what
>> security properties can be assured?
>
> Yes to all of the above, including the last.
The last question doesn't admit to a "yes" answer.
>> do you want to have a
>> kernel that handles both (twice as big), or do you want to build one on
>> top of the other (inefficiency)?
>
> I don't buy "twice as big".
Does the proof of correctness scale linearly with the size of the system?
More information about the cap-talk
mailing list