[cap-talk] Capabilities - the rub, an account - marcs' comments

Jed at Webstart donnelley1 at webstart.com
Sun Nov 26 16:10:49 CST 2006

At 01:35 PM 11/26/2006, Stiegler, Marc D wrote:
>...I thought the idea was to
>automate the unpleasant things so we could have more fun :-)


> > Arguably, users should chat to the sysadmin before delegating
> > non-trivial rights anyway, and the main problem here is the
> > barriers to communication between the users and sysadmin
> > rather than ACLs.
>... "I could run his life better than he
>does"...and the smart person would be correct about that except that it
>is a full time job to gather the "local knowledge" needed to run that
>one other person's life. And so it is with decisions about those with
>whom I should share my read and write access.


> > > I'm sorry,  but this is a
> > > rationalization of a situation which is fundamentally broken.
> >
> > Thats the cap POV.
>No, it is the POV of everyone who has ever had to wait a month for a
>sysadmin to take an action that obviously made sense to do immediately.

agree - as I indicated in a similar response.

>Or, yes, it is the cap POV, and all those millions of people who have
>waited for their sysadmins are cap people, they just don't know it.

I know it.

>Sure. This whole discussion started with Jed's assertion that caps had
>some problems that were solved by acls. A discussion of the advantages
>of caps is separate; in matters like this I have principally been
>arguing that caps are/can be/ just as good.

I agree.  I've been trying to focus on some "improvements" in
SOP that could provide much of the auditing/control that many
of the ACL people seek without putting an admin in the critical path.

>Though, embarassingly
>enough, in the examples I have given here, caps are actually better,
>because they break the veil of illusion. With caps, it is not possible
>for a central boss to confuse himself about what security policies can
>be enforced and then make everyone's life harder by trying to enforce
>the unenforceable, by forgetting-to-add/deciding-to-subtract the acl
>editing authority that people need to do further delegation. Note that
>they merely make life harder for the honest folk, they don't actually
>achieve any better security properties against the malicious folk,
>because, as you must be tired of hearing, people use email to circumvent
>the central boss's cooperation-hostile policy anyway.

I agree.  The John Walker spy case again comes to mind.

>Another thing this discussion reminds me of is the internal corporate
>wars that broke out when cheap copy machines were introduced (wow, you
>have to be an old guy to remember this). Lots of bosses at lots of
>companies were terrified that they would "lose control" of all the
>company's sensitive data, because the malicious employee could make
>copies of everything and send it to the newpapers and the competitors.
>The truth, of course, was more complicated. On the one hand, cheap easy
>copying did get used to steal sensitive data. But the overall benefit to
>the company of having information easily widely disseminated inside the
>company far outweighed the cost of the small increase in leaks. It
>outweighed the risks so fiercely that I know of no company in which this
>is even a matter of debate any more; only companies that embraced easy
>copying survived the transition. Eventually, easy proxying will win out
>in the same way, for the same reasons.

Do you mean "easy proxying" (which to me seems to assume an
implementation) or "easy delegation"?  I wish I was as hopeful as
you are MarcS that easy delegation will win out for the same
reasons.  As noted I do see some signs of hope on the network
front (URLs as capabilities being sent in email), but the OS front
seems a hard nut to crack.

>This too is the same whether we
>use caps or acls. It's just more obviously the correct thing to do when
>you approach it from a caps perspective.

When you use acls to implement communicable permission tokens
I still refer to them as "capabilities" just as I do when you use data
(e.g. cryptography) to implement communicable permission tokens.
I don't care too much what sort of subroutine I have to call to send
a permission as long as it gets done in what appears to me as one
simple step that is automated.

Where I feel the ACL term is appropriate are for those admin mediated
delegations, MAC, etc.  I realize this is a terminology issue, but I feel
that by focusing on the semantics of delegation we can both improve
communication and open up additional implementation possibilities
(e.g. using something like the encrypted 'address' mechanism for
communicating capabilities including tracking of a delegation path).

--Jed http://www.webstart.com/jed/ 

More information about the cap-talk mailing list