host Apparmor rules are applied to guests in spite of guests loading new rules

Apparmor is MAC - in my opinion it's not valid to have a container guest
specify its own policy.

However, the container should be entering a domain which protects the
host from the container, and in which executing any programs do not
cause more domain transitions (unless specified by the container's
policy).

This is something I want to discuss at UDS and implement during the
precise cycle.

Assigning to jjohansen just to toss him a warning that I'm looking to talk to him at UDS :)

Setting to medium priority because while 'a guest loading new rules' is invalid, host apparmor rules for daemons in the guest should not be applied.

Well I won't agree the guest shouldn't have its own policy (it depends on your use case), but I do agree the host should be able to set a domain to protect it self from the guest, but until AppArmor supports policy stacking the solution is either or.

The solution depends on what confinement is sought.

1. If the guest is to have its own policy, then the host needs to create a new policy namespace, and then it needs to transition the guest to the new namespace. Guest policy will then be loaded into the new namespace, and will not generally* conflict with system policy.

Setting up apparmor namespaces is a little clunky at the moment (a better interface is coming).
  You create a new dummy profile, and load using apparmor_parser -n <namespace> <profile>

This creates the namespace if it doesn't exist, and loads the dummy profile (the host can inject profiles into the container namespace). You then enter the namespace using the aa_change_profile call from libapparmor, unfortunately the command line interface to this isn't available in current releases, but I can provide the simple perl program. I would recommend transitioning into the unconfined profile (created by default as part of namespace creation) instead of the dummy, this allows the guest to behave as it would for normal system boot.

Instead of documenting the everything in detail here I am working on updating the wiki, and will drop a link to it here.

* The policy doesn't conflict but there are places where the guest can see that it is in a namespace. Eg. Messages from the kernel audit framework.

2. If the host is to confine the guest and disallow it from loading policy. You need to create a profile for the guest, it can be very broad but it should not allow capability mac_admin.

Long term the solution will be to use, apparmor namespaces as in 1, but with the aa_stack_policy command. Which will allow the host to retain its own policy and allow the guest to have a separate policy set that is controlled by the host. The goal is to allow a fake stacking for P, where the host policy is the unconfined state. This will allow for the same functionality of 1 but provide a stable api moving forward for when policy stacking is fully supported.

Quoting John Johansen (<email address hidden>):
> Well I won't agree the guest shouldn't have its own policy (it depends
> on your use case), but I do agree the host should be able to set a
> domain to protect it self from the guest, but until AppArmor supports
> policy stacking the solution is either or.
>
> The solution depends on what confinement is sought.
>
> 1. If the guest is to have its own policy, then the host needs to create
> a new policy namespace, and then it needs to transition the guest to the
> new namespace. Guest policy will then be loaded into the new namespace,
> and will not generally* conflict with system policy.

That's great - can the guest's namespace have constraints placed on
it by the host rules, which all domains in the guest namespace will
be subject to?

>> 1. If the guest is to have its own policy, then the host needs to create
>> a new policy namespace, and then it needs to transition the guest to the
>> new namespace. Guest policy will then be loaded into the new namespace,
>> and will not generally* conflict with system policy.
>
> That's great - can the guest's namespace have constraints placed on
> it by the host rules, which all domains in the guest namespace will
> be subject to?

Not currently, the plan is to allow for a restrictive stack of profiles where the
parent (host) rules will constrain on guests in the namespace, but its not
available yet.

This is fixed in precise, as containers now start in their own domain which will not transition further (i.e. to libvirtd).