WARNING

This document is a work in progress and requires at a minimum the development version of apparmor 4.x???

Requirements

AppArmor Kernel module - 4.x??
AppArmor Userspace - 4.x???

Introduction

If allowed by policy users can create their own profiles that will be applied against the applications run by the user. User defined policy when used does not replace system policy, instead it compliments it and is applied at the same time through stacking.

??? ======

creating and entering the namespace

system policy controlling user policy namespaces

System policy controls whether a user can create a policy namespace, what resources it can use and how it interacts with system policy. Specifically policy in the current namespace will control whether the user can load policy and any resources used will be accounted against the current namespace.

User owned namespace

User defined policy is stored in a namespace with limits defined by system policy. The namespace will be owned by the user and refcounted so that it will exist as long as a user task is running.

??? auto create and enter, vs. having the ns setup and already entered ??? entering ns needs to be early, before policy load because load task would be child or .profile

could be done as part of policy as a ns rule setuid -> &:ns:unconfined

or instead of being explicit part of the ns setup rule, and encode it as part of the policy to do that transition.

Permission to load policy

Permission to load policy into a user owned namespace requires either CAP_MAC_ADMIN (allowing a system admin to modify user policy) or the euid of the task attempting to load the policy to match the namespace's owner and any profile confining the task to allow policy admin.

user defined policy and uid changes dropping profiles when euid is switched