This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5
---------------
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium
* debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
* Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
exec_stack.sh fix mentioned above to more accurately test kernels older
than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
patch earlier in the series, as to match when it was committed upstream,
so that the above two patches can be cherry-picked from lp:apparmor
-- Tyler Hicks <tyhi...@canonical.com> Fri, 07 Oct 2016 05:21:44 +0000
** Changed in: apparmor (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
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/1628285
Title:
apparmor should be allowed to start in containers
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Xenial:
Fix Released
Bug description:
[Impact]
The kernel in xenial-proposed (4.4.0-46.67) and the lxd that has recently
migrated from xenial-proposed (2.0.5-0ubuntu1~ubuntu16.04.1) allows us to
enable stacked/namespaced AppArmor policy for lxd containers. This means that
the container can have an overall confinement profile while still allowing
individual processes inside of the container to have individual confinement
profiles. This bug is for the apparmor userspace changes needed to allow the
container init to load apparmor profiles during the container boot procedure.
[Test Case]
Install the kernel from xenial-proposed (4.4.0-46.67). Reboot into the new
kernel and set up a new xenial lxd container (MUST be an unprivileged
container):
$ lxc start ubuntu:16.04 x
Install apparmor from xenial-proposed (2.10.95-0ubuntu2.5) inside of
the container and reboot the container.
Verify that the container's dhclient is confined inside of an AppArmor
namespace with a stacked profile that was loaded inside of the
container:
$ ps auxZ | grep
'^lxd-x_</var/lib/lxd>//&:lxd-x_<var-lib-lxd>:///sbin/dhclient'
lxd-x_</var/lib/lxd>//&:lxd-x_<var-lib-lxd>:///sbin/dhclient (enforce) 165536
3889 0.0 0.0 16120 860 ? Ss 03:55 0:00 /sbin/dhclient -1 -v -pf
/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df
/var/lib/dhcp/dhclient6.eth0.leases eth0
[Regression Potential]
The regression potential is relatively high because processes inside of
Ubuntu containers can be confined with an additional profile that is loaded
inside of the container. However, this feature was released in Ubuntu 16.10
with no known issues so far.
[Original Description]
Now that we have support for apparmor namespacing and stacking,
unprivileged containers can and should be allowed to load apparmor
profiles.
The following changes are needed at least:
- Change the systemd unit to remove the "!container" condition
- Change the apparmor init script, replacing the current simple container
check for something along the lines of:
- If /proc/self/attr/current says "unconfined"
- And /sys/kernel/security/apparmor/features/domain/stack contains "yes"
- And /sys/kernel/security/apparmor/features/domain/version is 1.2 or
higher
- Then continue execing the script, otherwise exit 0
John suggested he could add a file which would provide a more reliable
way to do this check ^
In either case, we need this change so that containers can behave more
like normal systems as far as apparmor is concerned. That change
should also be SRUed back to Xenial at the same time the kernel
support for stacking is pushed.
This bug is effectively a blocker for snapd inside LXD as without
this, snap-confine and snapd itself will not be confined after
container restart.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1628285/+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
