[Apparmor-dev] Re: AppArmor FAQ

[Crispin Cowan]

Re-directed to apparmor-dev where this is more topical.

Rob Meijer wrote:
> Having said that, I feel a path based solution could have great potential
> if it could be used in conjunction with the object capability model, that
> I would consider a simple and practical alternative integrity model that
> does not require lables in an MLS maner, and that extends on the POLP
> concept in a way that would be largely more practical.
> That is, using 'thin' path based profiles would become very practical if
> all further authority can be communicated using handles in the same way
> that an open file handle can be communicated.
>   
While I am a fan of OC (object capability) systems, they have a
strikingly different design goal than AC (ambient capability) systems
like AppArmor.

    * OC makes capabilities explicitly visible to confined subjects,
      with 2 effects:
          o applications can achieve greater security by explicitly
            managing fine-grained permissions
          o applications *must* manage security by explicitly managing
            and delegating capabilities
    * AC is intended to secure legacy software that is oblivious to the
      access control schemes
          o applications don't need to be modified to exist in an AC system

AppArmor is intended to secure legacy applications, and so it is not
compatible with the goals of object capabilities.

However, it occurs to me that AppArmor could be extended in a simple way
to allow for object capabilities in the legacy UNIX way. Add a keyword
to the AppArmor language, lets say "delegated", so that some rules in a
profile might look like this:

    delegated:/** r,
    delegated:/usr/local/mycrap/** rw,

These "delegated" access lists would be be checked when ever a process
tried to access a delegated file descriptor, which would include:

    * FDs passed through UNIX domain sockets
    * the openat operations

The intended usage is that the "delegated:" rules would be considerably
more liberal than the standard rules. In the extreme they can be
completely liberal, granting "/** rwmix". This is a "safe" thing to do,
because they only apply to delegated FDs, and not to all access requests.

People who want to use AppArmor in the strict AC way simply don't use
these operations in their policies, and people who want to use object
capabilities can use them as desired.

This is open source, so if you want this feature, you do it. I would
accept such a patch. I likely would not want it added to the automatic
learning tools, because I don't think learning mode is really
appropriate to object capabilities, but perhaps OC experts might
persuade me otherwise.

JJ tells me that he also has some ideas for adding object capability
features to AppArmor that are different than mine. I'll let JJ post his
description if he wants.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com