[cap-talk] Capabilities and Freedom vs. Safety

[Jonathan S. Shapiro]

On Fri, 2007-07-27 at 07:46 +1000, James A. Donald wrote:
> Jonathan S. Shapiro wrote:
>  > If you proceed from these two assumptions, then the
>  > "disable A's access" really *is* reducible to the ACL
>  > problem, because you are trusting both B and B's
>  > software.
> 
> The ACL solution needs to be applied to individual
> programs, not just individual users.  Each user+program
> combination should have its own ACLs.

Do you mean to write:

	user + program

or

	user + program instance

?

If you mean "program", then what you describe has been done. Much of
what SELinux does can be viewed in this way, though SELinux has a
dynamic component as well. It certainly helps, but the existence of an
"own" right -- or more precisely, the authority of the owner to add
third parties to an ACL -- remains problematic.

If you mean "program instance", then what you describe is very
difficult. The problem is that new ACLs must be added and removed from
the system as new program instances are created. Several attempts have
been made to build such systems, thus far without success.

> A big problem with fine grained control is that chmod
> and the rest are already intolerably obscure for most
> users, and slicing them finer would doubtless drive the
> ordinary user completely up the wall if he had to employ
> the existing tools and existing model of permissions,
> sliced finer.

As has been stated before, this depends on how the fine-grained control
is managed. SELinux is a good example of the problem you describe. As it
happens, I've been sending notes with Dan Walsh about that this week.
There are really three distinct problems with SELinux:

  1. There is no well-documented theory of operation for SELinux
     as a systemic whole. This makes it very difficult for even an
     experience SELinux user (e.g. me) to update or revise the policy.

  2. The set of guarded applications grows all the time, with the
     consequence that the application interactions grow all the time.
     This makes the SELinux context labeling design change regularly.

  3. SELinux is good at capturing mostly-static properties, as for
     system daemons. It does not address dynamic policy at all.
     Dynamic policy isn't what SELinux was designed for.
     [Steve Smalley agrees with this characterization.]

Capabilities seem to work a bit differently, because they are not
managed explicitly in this way. Instead, the programs pass them around
under the "introduction" rule. This shifts the burden from the user to
the programmer, but it seems to do so in a fairly natural way.

> Both the Bifrost solution and the Microsoft solution
> have the user selecting from a small set of sensible
> options with workable default, rather than exercising
> control in the full detail of which the system in
> capable, though of course the Bifrost options slice
> control much finer than the Microsoft options.

Perhaps, but this isn't really relevant. What you are saying is that
Bitfrost and the MS system apply a form of factoring to permissions that
users find useful. You are further saying that capabilities cannot do
this. It is easy to see that this must be false: the Bitfrost and MS
permissions can be constructed on top of a capability substrate. The
reverse is not true.


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC