[apparmor] default profile

[John Johansen]

So with apparmor 3.0 we pickup a default profile that can be used to confine
init, without having to load policy in the initrd and then re-exec init

how this works is the default profile starts in the unconfined mode and init
in early boot is unconfined. Once the default profile is replaced
everything in the default profile picks up the new confinement.

to replace the default profile you define a new

profile default {
  ..
}

and load it, or if you want it to have default attachment

profile default /** {
  ...
}

or



there are a few rough edges around the default profile to be resolved yet.


1. selection

There is a Kconfig option that selects whether unconfined or the default
profile is used. And a kernel boot parameter that allows overriding the
selected default.

currently the override to select the default profile is
  apparmor.unconfined=0  or N

and to select unconfined
  apparmor.unconfined=Y

this option is fine but I'm not fond of apparmor.unconfined=0 We could
change this so that the apparmor= boot option could select the values, so
something like

  apparmor=unconfined

  apparmor=default

or something of the sort


2. default attachment

currently specifying the attachment may not be what you want it means that
px will always find a profile. This is different behavior from what you
would get with unconfined.

Instead a rule in the default profile can be used

  profile default {
    /** pix,
  }

This will retain the current unconfined behavior of other profiles px and
pix failing/inheriting if a profile is not defined.

Is this adequate? It certainly needs to be documented.


3. Profile/Namespace removal
Currently when a profile or namespace is removed it inherits the task
that where confined by the profile inherit the unconfined profile.

If the default profile is selected should this be inherited instead of
the unconfined profile.


4. ux

there is no equivalent ux, pux for the default profile, and I would rather
avoid dx, and pdx

Instead ux can be replaced with
  /foo px -> default,

but we have nothing to enable a fall back like pux
a glob rule like
  /** px -> default,

would come close as long as no other x rules used globbing and you
wanted the fallback to apply to all x rules (you usually don't)

We need to fix the overlapping x rule problem (this is just compiler work),
ie.
  /** px -> default,
  /usr/* px,

will currently fail to compile, but this still does not give use per rule
control of the fallback.

Finally we could introduce the explicit fallback that steve suggested years
ago

  /usr/bin/* px -> @{\1}, default, inherit,

(Note: syntax is just of the cuff and would need to be worked on)



Now to ux, should that even work when the default profile is selected
or should we just fail it, as ux remains away to escape confinement
and the default profile?


5. Tooling

Currently the userspace tooling does not work well with the default
profile or the unconfined mode. This needs to get updated. But the question
remains how aa-status et al should represent profiles in the unconfined
mode.

should it report them as confined, unconfined, ...