[apparmor] "default"/"system" profile

[John Johansen]

On 05/15/2013 05:13 PM, John Johansen wrote:
> So this is a new attempt to frame the default/init/system profile discussion
> 

Alright, here is a new proposal on it.

When a profile is created the first profile it is created with is the "init" profile.
- this profile is replaceable, and set as the default profile
- For the root namespace (namespace setup on boot)
  - this profile is setup in the unconfined mode
  - the name of this profile can be set by a kernel parameter
      apparmor.init=<name>
    or maybe
      apparmor.init_profile=<name>
  - the default name for the "init" profile could be any of (vote for your favorite)
    - init
    - initial
    - unconfined
    - something else???
- For all other namespaces
  - the first profile is the "init" profile, and it is set as the default profile
    - its name is set by the profile load that caused the creation of the namespace
      - namespaces are created by loading a profile to a child namespace that doesn't exist
      - the parent namespace can preseed policy in the child namespace
      - this allows lxc to setup a namespace that imitates real boot
    - its mode is set by the profile load

The default profile can be any profile in the system. That is just a regular profile that has been selected as the default profile
  - the "init" profile is the first default profile for a namespace
  - there is no set name for the default profile. That is the default profile is an attribute of the namespace
  - the default profile is set/changed by loading a profile that is marked as default
    - the marking is done as a profile flag
        profile foo (default) { }
      yes this can be combined with other profile flags
        profile foo (default, unconfined) { }
    - this allows the setting of what is default to be indicated within policy
    - the most recently loaded profile that is marked as default
    - loading of a profile that is marked as default and that is NOT a replacement for the current default does not do profile replacement on the current default
      eg. if "init" is the current default, and a new profile named "foo" is loaded and marked as the default profile, the tasks "confined" by init will remain confined by init, but the default profile will be switched to "foo" so that subsequent transitions to the default profile will transition to foo
  - transitions
    - u/Ux become a transition to the default profile
    - u/Ux becomes deprecated
      - we could replace it with d/Dx or something else as part of the policy language
  - replacement
    - if the default profile is replaced, its replacement becomes the default
    - unless another profile within the replacement set specifies it is the default
    - it is an error for an atomic replacement set to have to profiles marked as being the default profile
  - removal
    - removal of profile within the namespace causes a replacement to the namespaces default profile
    - if the default profile is removed, we could do any of the following
      - disallow the removal (unless the namespace is being removed)
      - set the default profile to unconfined mode, without actually removing it
      - replace with a profile named "unconfined" that is replaceable, and becomes the new default profile
    - if the namespace is removed
      - all profiles in the namespace, including the current default profile, are replaced by the parent namespaces default profile.
  - the default profile will be exposed to userspace via a file under its namespace in aafs
    - we could allow this file to be written to allow manually switching the default profile

Unconfined mode transition is pix based not pux based
- this allows tracking different task trees with separate unconfined profiles that might later be replaced.