Here is my understanding: 1. so long as a container has a profile specified, then if the apparmor policies have not been loaded, the container start will fail.
2. In the lxc-android-config case, the container has lxc.aa_profile = unconfined. Therefore it is possible for lxc-start (which normally has its own somewhat flexible profile) to run unconfined, but there will be no difference for the actual container. We consider the container to be the untrustworthy thing. per (1) if it is supposed to run in a profile and that profile is not loaded, the start will correctly fail. However lxc-start itself may run unconfined. I'm open to suggestions for how to enforce that it should be confined and is in fact running unconfined. But I can't think of any. The user could, and sometimes does, purposely run it unconfined, and I don't want to break that. I'd like to (after saucy) break /etc/init/lxc.conf into /etc/init/lxc- aa.conf and /etc/init/lxc-autostart.conf. lxc-net.conf would start on runlevel 2345, lxc-autostart.conf would start on started lxc-net.conf and lxc-aa.conf. lxc-aa.conf would start on filesystem, to load the apparmor policies as early as possible. We could then also have lxc- start fail if lxc-aa.conf is not started. The way to disable apparmor, in that case, would be to set LXC_AA=false in /etc/default/lxc. That way lxc-aa.conf could still start even if aa is disabled for lxc. ** Changed in: lxc (Ubuntu) Importance: High => Medium -- 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/1227937 Title: lxc-start is unconfined but has a profile defined To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1227937/+subscriptions -- Ubuntu-server-bugs mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
