So there is indeed no technical reason why apparmor wouldn't work in trusty containers as long as the host supports it (trusty with hwe kernel or xenial).
The reason why this wasn't enabled is due to concerns about apparmor profiles in trusty possibly needing updates to work inside containers. We've seen a fair amount of issues with AppArmor inside of LXD containers on Xenial behaving slightly differently from running on the host and didn't want to possibly cause regressions for longtime users (trusty) while we were ready to take that risk for xenial. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1686612 Title: Stacked profiles fail to reload in Trusty LXD containters Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: New Status in lxd package in Ubuntu: Invalid Bug description: Hi, in our testing I found an issue that might now surface due to stacked profiles working. Our setup is a Xenial (or newer) Host with LXD Containers for all supported releases. In that Xenial+ are good but recently the Trusty containers ran into an issue. After installing libvirt profiles are enforced and processes confined just as they should be. 3 processes are in enforce mode. [...] /usr/sbin/libvirtd (5253 All good so far, but once the Trusty container is rebooting it looses that. Libvirt is no more enforced and confined. I happen to find this being related: $ service apparmor restart "Not reloading AppArmor in container" Looking deeper I found that the newer Releases had code that uses is_container_with_internal_policy from /lib/apparmor/functions. That lets Xenial+ load the profiles in LXD correctly. But on Trusty the init script just calls /bin/running-in-container and if true will skip loading. For now I just drop this section in my setup via: sed -ei '/running-in-container/,/^\s*fi/{d}' /etc/init.d/apparmor I don't know what the support state of profiles in (Trusty) containers is, but I think more issues might arise out of this than just my libvirt profile. As I see it everything will fail to be confined after restart. This is not a regression per-se as before stacked was just not working at all. Now that it works this issue surfaces. In my case the eventual symptom was qemu guest failing to migrate between restarted and not restarted containers complaining that on the restarted one the apparmor security label is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1686612/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
