[apparmor] [Patch 0/1] RFC: apparmor profile directory

[John Johansen]

The following patch extends the interface with a namespace and profile
directory hierarchy.  The code is in an early stage and needs a fair bit
of work yet, but it is working well enough that it can be used to start
updating userspace tools and to make some decisions about its behavior.

The code creates the new "policy" directory with the layout shown in the
below example

/sys/kernel/security/apparmor/
  .load
  .remove
  .replace
  features/
  profiles
  policy/				# new policy dir
    root/				# root profile namespace
      control_XYZ			# ns control file
      profiles/				# profiles in the namespace
        9/				# profile sid
          name				# profile name
	  mode				# profile mode (enforce, complain)
          profiles/			# hats and children profiles
            f/
	      name
	      mode
	      profiles/
        1a/				# profile sid
          name				# profile name
	  mode				# profile mode (enforce, complain)
          profiles/			# children profiles
      namespaces/			# namespaces under root
        ns1/				# example sub ns
          profiles/
          namespaces/

The layout is incomplete as their are several files missing for both
profiles and namespaces. Eg. profiles are missing attachment information
and access to the policy dfa, and the control_XYZ file under the namespace
is NOT an actual file but just a place holder to show where namespace
control files will fit into the hierarchy.

Currently the root ns dir is the only entry under policy but I think this
should probably be folded into the policy directory, as namespaces are
hierarchical and there will not be another entry in policy.

Profiles are listed within a namespace directory by their sid. This is
because a profile name can contain '/'s which are not valid characters in
a file name. Currently the sid is output as a hex value, should this be
changed to decimal or some other representation?

Within the profile directory the sid is not listed as a file entry should
it be?

The name and mode files list their values without an append '\n'. Should
a trailing '\n' be added to make looking at these values from the cmd
line cleaner.

The child profiles and hats directory is currently created regardless of
whether child profiles or hats are present.  Should this directory only
be created if the profile has children?

The implementation currently creates and removed file entries when a
profile is loaded or removed which means we are always allocating the
dentries and inodes necessary for all profiles loaded into the system.
While this is adequate for a first pass it would be better if this could
be more dynamic and we could create the majority of these only if they
are looked at.

The static allocation also can current result in a weird failure where
profiles can be added/replaced but the creation of the interface files
will fail such that it is impossible to see that the profile exists.

Fixing this will be challenging for the replacement case because the old
interface files need to be removed before the new ones can be added. If
an error occurs during adding the new files we can not roll back to the
old ones as they have already been removed.

The policy directory is not virtualized in the current code so that if a
task is in a differect namespace it does not see its ns as the root. This
is problematic, and needs to be fixed. I have played some with using vfs
operations to fake virtualize the directory, but this is problematic and
will likely be rejected upstream. An alternative approach is to have the
kernel create a bind mount when a task requests switch to the new namespace,
I haven't played with this at all yet and it will need to be explored more.