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

Jed at Webstart donnelley1 at webstart.com
Sun Nov 26 14:48:32 CST 2006


At 12:17 AM 11/24/2006, John McCabe-Dansted wrote:
>On 11/23/06, Marc Stiegler <marcs at skyhunter.com> wrote:
> >
> > John McCabe-Dansted wrote:
> >At 09:03 AM 11/18/2006, Marc Stiegler 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.

Which is of course what people were referring to.  That overhead is
so huge as to make the whole approach unworkable.

>Arguably, users should chat to
>the sysadmin before delegating non-trivial rights anyway,

I take issue with both the chat with the sysadmin (I am one)
and with "non-trivial".  I believe this whole approach is so
broken that it's hardly worth talking more about, but if anybody
wants to continue to defend it I'll stay on the attack in more detail
if needed.

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

Perhaps, but a point of view informed by years and years and
years of daily experience.  I administer some 5 Unix systems.
Even with only some 10 of them with substantial user communities
(most simple servers like syslog, IDS, etc., etc.) the dealing
with ACL issues is so onerous that most users don't even bother
unless they have a huge need.  Consider that approach at the
process level (POLA?)?  Of course not.  Does it even work at the
people level?  I argue no.  The only reason we survive is because
we can copy things through email as MarcS noted.

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

Sigh.  The need to get a person involved in every access control
delegation is just ...  Well, I feel I can't go on with this topic and
remain respectful.

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

Where does this "one minute" number come from?  That is just so far
from any reality that I've experienced.  First of all you of course have to
deal with the fact that the person you're looking for will usually not
be available (in a meeting, on travel, working on something higher
priority, etc.).  That "one minute" so often turns into 3 days to a week.

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

I think he means just send off a copy of the data.

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

At that level you are back to talking about authentication for
the purpose of establishing identity and access to a base set
of permissions.  I hope it doesn't look to folks like I'm flip flopping
here, but I believe that sort of policy and controls are needed and
relevant.  What I don't believe are effective are mechanisms that
require a third party administrator to get involved in delegation
decisions by users or processes.

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

Here I'll agree with something Alan keeps coming back to:

At 08:01 PM 11/25/2006, Karp, Alan H wrote:
>Hence, any mechanism should
>allow users to be Oblivious of the rules.  Of course, the bottom line is
>Compliance with policy.  Voluntary Oblivious Compliance.
>
>I believe that the goal of having sysadmins control changes of
>permissions is to achieve VOC.  It may work, but it's a clumsy tool.
>It's so clumsy that people find workarounds, such as sharing passwords,
>that are far worse than the problems it solves.

I agree with the above from daily experience for many, many years.

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

I agree with the above which I think is again from MarcS.  I don't believe
'traditional' (e.g. DVH) capability system provide mechanisms for
tracking accountability.  Perhaps the CapWiki does.  I'm hoping we
can discuss this topic more Friday.

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

There I believe we can change common practice and make
the techniques that are most easily and commonly used
also those that provide for the best compliance (using
Alan's term).

>If we pass rights around by giving other users simple
>copies of the caps, all accesses will appear to come from the
>sysadmin.

Right, so that's not the approach to use with capabilities.

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

Hurray!  Now were right back to where I feel 'the rub' is.  I believe
we can't achieve any reasonable level of (you name it, 'security',
'compliance' with policy, access control, etc.) using mechanism
that have to go through people for management - such as
ACL mechanisms of that type (distinguish from ACLs used to
implement capabilities - e.g. as:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

), but I do believe we can achieve good (you name it...) using
mechanisms based on object/capabilities (though perhaps with
relatively minor augmentation for sensitive situations).

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

Although I wouldn't state it like the above, I think we agree on the
essence of what you're getting at - which I hope I've addressed elsewhere.

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

Hmmm.  At this point I'm sympathetic.  However, what you seem
to be asking for is blocking communicating conspirators.  This is
difficult to impossible, but I think we agree that we should do the
best we can.

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




More information about the cap-talk mailing list