[cap-talk] Capabilities - the rub, an account
marcs at skyhunter.com
Wed Nov 22 17:11:42 CST 2006
John McCabe-Dansted wrote:
>> Indeed, you have made an assumption about functionality in acl systems
>> that is not present in any popular acl implementation. It is not
>> possible for the holder of a read authority to delegate that read
>> authority to another person using the acl system. Only proxying as I
>> described earlier is possible. Why? Because for me to give Sarah an
>> explicit read permission, I must have acl-entry-editing permission. If I
> In practice this is commonly achieved by asking the sysadmin to give
> Sarah your access. Although this habit has considerable overhead, it
> also has some advantages as the sysadmin should be aware of the
> security implications of delegating certain rights and advise the user
> as to which exact rights they want to delegate. This would also allow
> us to find out who misused the right, either directly or indirectly by
> setting up a proxy in violation of company policy.
"Considerable overhead", oh, lordy, yes. I'm sorry, but this is a
rationalization of a situation which is fundamentally broken. I have
earlier told the story, for this specific thread, of how I one day
learned that I had authority to edit the entire app-server for HP Labs.
This came about as the solution to the following problem: one of the
pieces of software on the app server was a piece of software I was
developing, being used in a pilot program involving people from all over
the company. The local IT guy did not have the acl-editing authority
needed to give me direct access to the folder containing software for
which I was the only person in the company capable of judging its
correctness and validity. So for months, until a higher level of IT
dealt with it, I would send him email (real people use email, not acls!)
with attachments and instructions on what to replace in the folder. On
good days he got it right. On bad days he got it wrong and we'd do it a
second, and a third, time. He never had any clue what the heck I was
putting there, had no method for assessing its goodness or badness, for
the obvious reason that it was my software.
There were no winners in this ridiculous game. No winners, no
justification, no sense. Only losers. We all wasted a lot of time on
this silliness for no benefit to anyone.
Meanwhile, if I'd been intent on breaking company policy, I would have
done so without talking to the admin, by using...email! Probably Gmail
or YahooMail so they wouldn't have a record in the company servers either.
> It seems like the information "which user actually did the `bad'
> access" is useful,
Neither more nor less possible than in an acl system. Again, what you
get is not, who did the bad, but who to hold accountable for the bad.
Which is good! It is what you want and need! What is the peculiar allure
associated with the illusion that you can really know who actually did
the action, when in fact half the executives in functionally effective
companies give their full-power passwords to their admins, and half of
the rest have passwords weak enough anyone can use them?
Note that, in the true life situation I described above, the solution
for getting better accountability is the same in both acl and cap
systems: the higher-level IT guy grants me my own authority (either a
cap or an acl entry) which is then logged separately from the accesses
done by my local IT guy. Or better, my local IT guy has an authority to
have a cap created and sent via email to my HP email address, again a
separately loggable cap.
More information about the cap-talk