[apparmor] apparmor query interface spec and changes

[John Johansen]

So I know peoples eyes are going to gloss over but please stick with it
and at least think about this because its on tuesdays meetings agenda,
and it has relevance to the LSM discussion about userspace APIs that
Simon just forwarded (https://lists.ubuntu.com/archives/apparmor/2015-February/007177.html).

Currently the apparmor kernel proc interface and peersec label (that are
shared with other LSMs) reports confinement as a "profile (mode)" pair,
except in the case of unconfined which is reported as just "unconfined"

There are however a couple of extensions to apparmor that are about to
land (or have partially landed in Ubuntu) that have interesting
ramifications on what is reported.

The first is the new user accessible unconfined mode. This will allow for
a profile to behave as if it is the unconfined profile, except that execs
will track the profile. This feature is used by the new default profile
boot parameter that allows setting a default profile other than
unconfined. This default profile starts in an unconfined state and then
well its profile is loaded it can be switch into enforcing mode (for more
background see the previous thread about replacing unconfined
https://lists.ubuntu.com/archives/apparmor/2012-April/002537.html, and
https://lists.ubuntu.com/archives/apparmor/2013-May/003710.html). Anyways
profiles in the unconfined mode show up as
  profile (unconfined)

while the current behavior of the unconfined profile, which is the
standard default profile remains as
  unconfined

this was done for backwards compatibility with tools but could be changed for consistency
  unconfined (unconfined)

I don't think there is really a need, unless anyone objects, we just need
to make sure the tools are updated to handle the new unconfined mode.


The other big change is the new compound label names and stacking. There
are several issues to discuss related to this feature. First this can
result in reported names that contain more than one profile
  eg. profile1//&profile2

If profile names are long, or there are lots of profiles in the compound
name, the string could become to large for the buffer. There are several
things that can be done to combat this.
- use short profile names and provide a separate attachment specification
- allow specifying an alias for common name combinations. This will
  likely be desired for cipso support because the name buffer is short
- compress the name and encode and report that if it fits. I don't like
  this and currently have no plans to implement it
- if all else fails report the numeric secid
  #123123123
  which then can be used to query the custom apparmor query interface


the real question comes when reporting the mode.  Each profile can
theoretically have a different mode, so we need to report multiple modes.
Currently the code reports the mode in the same order as the profiles
in the name string, using only the first letter of the mode to try and
keep the mode short.
  eg.   profile1//&profile2 (EC)

we could report the full mode names but that would result in longer mode
strings, leaving less remove for the profile names, and actually require
more work to update the parsing of our userspace tools. Keeping it short
also has benefits for none apparmor specific tools (eg. ps -Z)


the third issue to make sure we nail down is around namespace visibility.
With stacking it becomes possible to have profiles from different
namespaces confining a task simultaneously. For example the host might
want to limit what an lxc container can access, and the lxc container
being run as a virtual OS may have its own policy on the processes that
are running.  So for a host using the confinelxc profile on lxc, and an
lxc process running apache inside a policy namespace of containerA, when
queried from the host we could have something like
   confinelxc//&:containerA://apache (EE)
and when queried from in the container, only
   apache (enforce)

that is the interface is virtualized along the namespace hierarchy, a
task can only see anything at or below its current namespace. The
question is, is this the default that we want for the proc interface or
should it only report the profiles from the current namespace?
   ie. for the above example, either
     confinelxc (enforce)
   or
     apache (enforce)
dependent on who does the querying

If we decide to make the proc interface show only the current namespace
profiles we would need to add to the apparmorfs interface a way to query
the hierarchy, as it does have its uses.


Now to the writable end
currently apparmor uses all potential character including embedded \000
characters as part of its interface, ideally we don't want to change this
(for backwards compatibility reasons) but if it becomes necessary so there
can be better unified LSM interfaces we need to start pondering what could
be done. I don't have any specific issues or recommendations, I just want
to point it out as a potential issue and that you might want to look into
the LSM discussion (mentioned above)