[apparmor] [Kerenl Patch 0/32] RCU locking and interface

John Johansen john.johansen at canonical.com
Sat Jan 19 14:12:20 UTC 2013

On 01/16/2013 01:28 PM, John Johansen wrote:
> So this is the latest iteration of the new profile locking and profile/
> namespace directory. There has been no changes to the dir layout since
> last time but several bug fixes
> eg.
> /sys/kernel/security/apparmor/
>   .load
>   .remove
>   .replace
>   features/
>   profiles
>   policy/			# new policy dir
>       profiles			# profiles in the namespace
>         usr.bin.foo.9/		# sid-mangled profile name
>           name			# profile name
> 	  mode			# profile mode (enforce, complain)
>           attach		# attachment re string
>           profiles/		# hats and children profiles
>             bar.12/
> 		name
> 		mode
>       namespaces/		# namespaces under root
>         ns1/			# example sub ns
>           profiles/
>           namespaces/
> The RCU patches where reworked fixes several subtle race conditions.
> patches 1-16 should already have Acks on them from review, and
> patches 28-32 are there to provide a fully functional system, and should
>               not be review atm
> Some of the new patches are setting up for changes required by the
> coming labeling patches (eg. changing how 21/32 changing how profile
> replacement is handled)
> The other set of new patches are to allow specifying a default profile
> from boot which makes doing total system confinement much easier
> So once again, the set of patches that a

A few more notes, on usage and testing

If the kernel is compiled with unconfined as the default (the kernel
in the ppa is built this way), you will need to add the kernel parameter


to the grub command line.

The system will then boot with all processes (including init), that don't
have a profile loaded, in the "default" profile with the mode set to
"unconfined" (so anything that previously would have been unconfined)

so introspection on a task from the command line

 > cat /proc/self/attr/current
 default (unconfined)

the default profile can be replaced, and once its replaced all tasks
that have the default profile set will switch to the new default
profile. Loading a default profile in early boot allows for total
system confinement without having to put policy in the initrd
(assuming you can trust early boot).

Please note at this time aa-status does not work correctly with
the default profile. It reports all profiles with default as being
unconfined but having a profile defined.

The "unconfined" mode can be set on any profile if the 3.0 userspace
is used. This allows seeding namespaces with their own default
unconfined profiles. This does not replace the "unconfined" profile
which still exists and can be transitioned to using u/Ux or named
profile transitions.

The basic sequence to create a namespace and run a process in it,
is to create a dummy profile and load it to create a new namespace,
and then exec a task in the namespace. Note that the dummy profile
does not have to be used but is necessary to create and pin the
namespace; this will be fixed in the future

> cat profile.dummy
profile dummy { }
> sudo apparmor_parser -n demo_ns profile.dummy
> aa-exec -p :demo_ns://unconfined bash

To seed a namespace with its own default profile like is created
by setting apparmor.unconfined=0, do

> cat profile.default
profile default (unconfined) { }
> sudo apparmor_parser -n demo_ns profile.default
> aa-exec -p :demo_ns://default bash

Any profile could be loaded and used, there is nothing special
about default, and unconfined exists for all namespaces.

More information about the AppArmor mailing list