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. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/876968 Title: host Apparmor rules are applied to guests in spite of guests loading new rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/876968/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
