My current situation is matching Johns comment, since the Host is Xenial
in my case all "would" run just fine - and it does seem to work, except
of the fact that while loading fine due to the postinst loading them on
reboot they are skipped.
On a not representative scan on my system in /var/lib/dpkg/info I found my
assumption confirmed that many packages do call apparmor_parser to load
profiles in postinst.
I'm sure there are more, but for me that would be: "cups-browsed cups-daemon
digikam firefox haveged ippusbxd isc-dhcp-client libvirt-daemon-system
libvirt-daemon-system libvirt-daemon-system lxc-common ntp rsyslog snap-confine
squid tcpdump telepathy-mission-control-5"
I checked if libvirt might be special here, but it is not.
They all seem to use the same guard which is "aa-status --enabled".
Now in the past "running-in-container" was always true at the same time when
"aa-status --enabled" was false - so the behavior of all the postinsts matched
what the service did on reboot.
But that is no more true, on a recent kernel/lxd "aa-status --enabled" is true
in the container.
I like that LXD tries to stay neutral to the image, but I wonder if in apparmor
init the old check of "running-in-container" could/should be replaced with a
check more similar to "aa-status --enabled".
Eventually the code for newer releases is just that as it lets LXD with stacked
namespaces through via the latter check in:
if systemd-detect-virt --quiet --container && \
! is_container_with_internal_policy; then
So could there be a "is_container_with_internal_policy" version for
trusty that fixes all packages at once?
--
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
