[apparmor] AppArmor stacking

[John Johansen]

On 01/25/2016 04:46 PM, Seth Arnold wrote:
> Hello,
> 
> I thought our stacking discusssions might go better if we've got some
> concrete examples of how stacking could be or will be used:
> 
> 1. lxc/lxd/docker containers that use AppArmor to help enforce host
> security from the contained applications while still allowing the
> contained applications to use AppArmor as if they were running in a
> standard system instead. AppArmor may also be used to keep the different
> containers from influencing each other, or allow influencing each other
> only through defined mechanisms.
> 
this is what I would call the primary use case atm

> 2. The system administrator may want to use pam_apparmor to enforce that
> users can't gain administrative privileges while administrative users can.
> All PAM-based ways users gain access to a system get a generic profile
> applied that only allows the handful of capabilities needed for e.g.
> password changes via child profiles.
> 
sure, essentially a per user profile in addition to application profiles.
Not that I think system application profiles at the user level are all that
good. It works okay for single user systems where the user can tune policy
for their use, and okay for a role based access where the role is augmented
by per application policy, but not so good for general multi-user systems.

That being said it can work well in the android type system where the user
doesn't have the ability to change the policy being applied to an application,
and data access is really locked down.

However, what works even better for this is a tight application profile
and delegation. The problem with stacking for this use case is profiles
must be broad and rely on other profiles to tighten, instead of just
containing the minimum set of privileges needed.



> 3. The system administrator may want to use pam_apparmor to enforce that
> users are separated or only interact with each other in specific ways.
> This profile would probably include extensive use of 'owner' rules.
> 
sure, I think this case also covers rbac as discussed above

> 4. Users may think distro-provided or admin-provided profiles for
> applications are too loose and don't mind trading some usability for
> drastically tightening the permissions of the applications they use.
> 
> I can even see several of these in use simultaneously on one machine.
> 
yes, and no. At least currently this will require some modification of
system policy. Which isn't that different than just stripping the permissions
from application policy (it may be that less total change is required).

Where this really becomes viable user user policy namespaces. Where the
user gets their own policy namespace and can apply their own policy to
their tasks, regardless of system policy (no modification to system
policy will be required). We aren't going to be at this level yet,
though I suppose when combined with user namespaces, we sort of will be.

> Have I missed any use cases? (I think it'd be worth fleshing these out to
> the point where they'd make nice guides on the wiki or docs or blog posts
> or something.)
> 
> Thanks
> 
> 
>