[apparmor] whither unconfined? trap profiles and deny

[John Johansen]

So this is just to get some feed back on whether we want to do anything
more with controlling the unconfined profiles domain transitions.

Currently there is no explicit way to deny the execution of an
application from unconfined. But we do allow controlling which profiles
will attach via the profile name or attachment specification.

  /bin/foo { ... }
and
  profile foo /bin/foo { ... }

And unconfined essential has an exec rule of
  /** pix,

There are occasions when one would really like to be able to deny the
execution of an application, but currently we don't have a way to specify
this.

One way around this is to define a trap profile, which will attach to
the application but give it no permissions.

  /foo/bar { }

While this works it has some unfortunate side effects and is of limited
use.  First it actually allows the exec but then denies all accesses after
so that the logs fill up with rejects events while the newly executed
profile dies.  This can be mitigated by putting deny rules in the trap
profile but doesn't fix the problem of the extra work the system does by
allowing the exec to complete and then terminating the process.

The other problem with trap profiles is that they can be worked around on
many systems by using hard links, as unconfined does not put any
restrictions on what hard links can be made.  Even so the trap profile
does have its limited uses.

One possible extension is to allow deny rules at the profile level.  Eg

  deny /foo/bar,
  profile /foo/bash { ... }

Which would fix the first problem with trap profiles but not the second.
To deal with the second we need to mediate what hard links a confined
application can make.  We can deal with this in a few different ways.

1. Deny hard links from unconfined to executables that have a profile
   defined.  This provides an easy automatic control of what hard links an
   unconfined task can make, and tying it to the attachment rules make
   sure its always in sync with loaded policy; but it adds magic, and loses
   some of the control that is currently available, ie. what if you
   really do want to allow a hard link to an application with a profile.

   Perhaps even worse it doesn't mediate other possible forms of alias
   from privileged applications like mount.


2. Use a default global profile.  Basically if you really want this
   type of restriction define a /** { ... } profile and load it early.
   This provides the full controls that a profile would with out
   conflating what unconfined is.

   The problem with this is that unless /** { ... } is defined in the
   initrd then some programs (init, ..) will still be in the unconfined
   state.

   It also suffers from the link rules of /** not being automatically
   up to date like in 1, even though the exec transitions will be okay as
   long as px, and pix are used.


3. Allow replacing unconfined with a profile.  This would fix the
   problem with #2, but then unconfined would mean something
   different, and you couldn't easily determine what was meant when the
   a task was label as unconfined


4. Allow a renaming replace of unconfined with a profile.  The
   idea is to replace unconfined as in 3 but with a profile of a
   different name, say /**, so when introspection occurs unconfined
   does not show up for any task that has made the transition to
   being confined by the new profile.


The question really comes down to how do we want to define policy. Is it
worth extending the language to add the deny rule to allow for
simplistic denies of application execution, or should we just require
using a profile for these situations and if so do we want to allow for
full coverage or only for applications loaded after the profile is
defined in the kernel.