[cap-talk] Capabilities - the rub, an account

[Marc Stiegler]

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.

--marcs