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

John McCabe-Dansted gmatht at gmail.com
Fri Nov 24 02:17:12 CST 2006


On 11/23/06, Marc Stiegler <marcs at skyhunter.com> wrote:
>
>
> 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.

Editing an ACL takes less than a minute. Basically the overhead is in
getting the attention of the sysadmin. 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'm sorry,  but this is a
> rationalization of a situation which is fundamentally broken.

Thats the cap POV.

> 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

The local IT guy clearly had write access, so we could give him
acl-edit authority without having to give him (from the cap
perspective) any more rights.

There is a strong argument for giving the local IT guy the right to
delegate rights to other users. Administering the system is his job,
so logically he must have the right to administer.

OTOH, the case for giving e.g. a data entry operator edit rights is
much less clear. They have a clearly defined job, and delegating
arbitrary rights is not part of it.

> 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

This could be fixed with a change of culture rather than a change of
security model. If there was good communication a one-minute trip to
the IT guys office could have fixed this under ACLs.

> 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.

I don't understand how using Gmail or YahooMail would have helped you here.

In any case this argument seems weak when applied to users. The HP
policy was too restrictive, however all major corporations have
policies about who their staff are allowed to trust with their
passwords, keys, access cards, etc. Sysadmins can scan for malware
that proxies rights. Users usually don't set up proxies that share
access to the company database with their penpal. Users who know
enough to set up such a proxy usually know enough to know the risks.
Just because it is possible to break company policy doesn't follow
that we should actively try to make it easier.

> > 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,

It is possible to write code that is free of confused deputy bugs,
without using caps. But you cannot simply write code the obvious way.
Likewise is possible as we have both suggested in this thread, to pass
capabilities around in such a way as you have as much information as
you do under ACL. However this is not true if you do this the
"obvious" way. If we pass rights around by giving other users simple
copies of the caps, all accesses will appear to come from the
sysadmin.

The typical cap response, is that you *can* do things like attach a
revoking or logging proxy to the cap before passing it on. This
response does not convince the ACL crowd that caps are as good or
better than ACLs, nor do I believe that it should. We need to convince
them that  that innocent users *will not* pass rights the obvious way.
 We can not assume that non-technical staff will understand the
difference between sending their own caps and sending a cap wrapped in
a revoking or logging proxy.  The system should make the "obvious" way
of sharing caps between users non-obvious. Indeed, IMHO the system
should prevent unwrapped caps from ever being sent between users by
always rewrapping the caps.

Further, when promoting caps we should make it clear that we intend
for the system to ensure that transfers of caps between high-level
entities such as users are always logged and revocable. Even if a
buggy/malicious application conspires to automatically proxy rights
unlogged, then it should be possible to revoke the rights by
destroying the application, and also allow the user to monitor data
entering or leaving their account e.g. to set up an IDS.

Even if we assume users actions are infallible there is still the case
where they leave their terminal logged in. In the good ol' days we
didn't give users write access to startup scripts or macros, so if
someone found a logged in terminal they couldn't get any rights that
lasted beyond a logout. It would be nice if we could regain this
property, to do this we would have to  require users to jump through
hoops to grant permanent rights, either by contacting a sysadmin or
reauthenticating like "sudo myself-admin".

> 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.

Or equivalently, the IT guy has an acl-edit capability?

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia


More information about the cap-talk mailing list