[cap-talk] More Heresey: ACLs not inherently bad

[Karp, Alan H]

Marcus Brinkmann wrote:
>
> These are false alternatives.  Unix is more powerful, and I am sure
> you know how this can be implemented correctly in Unix using file
> descriptors.  There are at least three ways:
>
Your alternatives work, but as you recognize and as Norm points out in his paper, finding all the places that need patching can be a challenge.  The simplest solution is to take the capability approach and have the arguments be open file handles rather than strings.
>
> > Here's an example I've been using.  Alice wishes to use Bob's backup
> > service, which is implemented by using Carol's copy service.
> >
> >        Alice: bob.backup(foo)
> >        Bob:   carol.copy(foo,bar)
> >        Carol: copy(a,b) { b.write(a.read()); }
> >
> > Show me how to do that with setuid without violating least privilege.
>
> 1. Carol's copy service can run with root privileges.  Then it can
> assume any user ID, including that of Alice or Bob.

Which violates least privilege.
>
> 2. As is well known, capabilities can be emulated with an inflation of
> ACL IDs: A group carol-and-alice can be used to give Carol access to
> Alice's file, and a group carol-and-bob for the mediation of Carol and
> Bob.  But, to make this work, you probably also need an inflation of
> processes with appropriate setgid and setuid privileges (plus a
> supervising master process only accessible to carol) to go along with.

I'll take that to mean this approach doesn't solve the problem.  For example, Alice may not be the owner of the file and can't change its ACL to add the carol/alice group.
>
> 3. Alice and Bob can give file descriptors (== Unix capabilities) to
> Carol.  As this is the capability solution and doesn't use setuid, I
> consider it cheating in this particular example.

Agreed.
>
> Don't knock the first two options too quickly.  To pull your example
> back into the real world: three-way negotiations are very complicated
> and tricky business.  Until you go into more detail, I am going to
> assume that the negotiations between Alice's, Bob's and Carol's
> lawyers and the resulting contracts and business models are going to
> cost many times more than a dedicated machine for Carol on which the
> copy service is implemented, or a contract between Carol and root for
> running the copy service or at least for creation of the necessary
> user IDs.
>
Least privilege is about limiting risk.  Even if the contracts state that Carol may access any files that Alice and Bob designate, that doesn't mean that Carol may access any file that Alice and Bob may access.  More particularly, it doesn't mean that Carol may write a file that Alice only needs Carol to read.

My example comes from the real world.  It is an abstraction of a use case that the US Navy has been working on for about five years.  In fact, the Navy just ran a major LTE (Limited Technical Experiment) using Attribute-Based Access Control for this problem.  When pressed, they admitted that they could get either the required functionality or the required security but not both at the same time.

The Navy case is even simpler because there are no parameters.  Alice invokes Bob's service.  In order to satisfy her request, Bob invokes Carol's service.  Their problem is knowing whose authentication to use on that second request.  They chose to use Provider Chaining from the Liberty Alliance SAML profile, which presents both sets of credentials to Carol.  The problem with that if Bob constructs the SOAP body (basically the method invocation) is that he gets to use all of Alice's permissions, a serious violation of least privilege.  If Carol will only accept a SOAP body signed by Alice, functionality is seriously constrained.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp