LXD mounts /sys/kernel/security as upstart and systemd won't let the
system boot if that's not mounted (and they can't mount it themselves).
LXD also doesn't differentiate Ubuntu 14.04 from Ubuntu 16.04, or any other
distro or release.
Instead we provide the exact same environment to every container, just like a
VM would. The users can define extra things on top of that, but the source
image that's used has no impact on that.
If something is directly loading profiles, bypassing apparmor's own check, then
it's either a problem in that software in the first place or a problem with the
apparmor tools which should match the init behavior and refuse to operate in
unsupported environments.
** Changed in: lxd (Ubuntu)
Status: New => Invalid
--
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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
