[Bug 1628285] Re: apparmor should be allowed to start in containers
Launchpad Bug Tracker
1628285 at bugs.launchpad.net
Wed Jan 18 17:28:28 UTC 2017
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5~14.04.1
---------------
apparmor (2.10.95-0ubuntu2.5~14.04.1) trusty; urgency=medium
* Bring apparmor 2.10.95-0ubuntu2.5, from Ubuntu 16.04, to Ubuntu 14.04.
- This allows for proper snap confinement on Ubuntu 14.04 when using the
hardware enablement kernel (LP: #1641243)
* Changes made on top of 2.10.95-0ubuntu2.5:
- debian/apparmor.upstart: Remove the upstart job and continue using the
init script in 14.04
- debian/apparmor.postinst, debian/apparmor-profiles.postinst,
debian/apparmor-profiles.postrm, debian/rules: Revert to using
invoke-rc.d to load the profiles, rather than reloading them directly,
since 14.04 will continue using the init script rather than the upstart
job.
- debian/apparmor.init, debian/lib/apparmor/functions,
debian/apparmor.postinst, debian/apparmor.postrm: Remove functionality
dealing with AppArmor policy in system image based environments since
this 14.04 package will not need to handle such environments. This
removes the handle_system_policy_package_updates(),
compare_previous_version(), compare_and_save_debsums() functions and
their callers.
- debian/apparmor.init: Continue using running-in-container since
systemd-detect-virt doesn't exist on 14.04
- debian/lib/apparmor/functions, debian/apparmor.init: Remove the
is_container_with_internal_policy() function and adjust its call sites
in apparmor.init so that AppArmor policy is not loaded inside of 14.04
LXD containers (avoids bug #1641236)
- debian/lib/apparmor/profile-load, debian/apparmor.install: Remove
profile-load as upstart's apparmor-profile-load is used in 14.04
- debian/patches/libapparmor-mention-dbus-method-in-getcon-man.patch:
Continue applying this patch since the dbus version in 14.04 isn't new
enough to support fetching the AppArmor context from
org.freedesktop.DBus.GetConnectionCredentials().
- debian/patches/libapparmor-force-libtoolize-replacement.patch: Force
libtoolize to replace existing files to fix a libapparmor FTBFS issue on
14.04.
- debian/control: Retain the original 14.04 Breaks and ignore the new
Breaks from 2.10.95-0ubuntu2.5 since they were put in place as part of
the enablement of UNIX domain socket mediation. They're not needed in
this upload since UNIX domain socket mediation is disabled by default so
updates to the profiles included in those packages are not needed.
- Preserve the profiles and abstractions from 14.04's
2.8.95~2430-0ubuntu5.3 apparmor package by recreating them in the
top-level profiles-14.04/ directory of the source. They'll be installed
to debian/tmp/etc/apparmor.d/ during the build process and then to
/etc/apparmor.d/ on package install so that there are no changes to the
shipped profiles or abstractions. The abstractions from
2.10.95-0ubuntu2.5 will be installed into
debian/tmp/snap/etc/apparmor.d/ during the build process and then into
/etc/apparmor.d/snap/abstractions/ on package install for use with snap
confinement. Snap confinement profiles, which includes AppArmor profiles
loaded by snapd and profiles loaded by snaps that are allowed to manage
AppArmor policy, will use the snap abstractions. All other AppArmor
profiles will continue to use the 14.04 abstractions.
- debian/rules: Adjust for new profiles-14.04/ directory
- debian/apparmor-profiles.install: Adjust to install the profiles that
were installed in the 2.8.95~2430-0ubuntu5.3 package
- debian/apparmor.install: Install the abstractions from the
2.10.95-0ubuntu2.5 package into /etc/apparmor.d/snap/abstractions/
- debian/patches/14.04-profiles.patch: Preserve the 14.04 profiles and
abstractions from the 2.8.95~2430-0ubuntu5.3 apparmor package.
- debian/patches/conditionalize-post-release-features.patch: Disable new
mediation features, implemented after the Ubuntu 14.04 release, unless
the profile is for snap confinement. If the profile is for snap
confinement, the abstractions from /etc/apparmor.d/snap/abstractions
will be used and all of the mediation features will be enabled.
- 14.04-add-chromium-browser.patch,
14.04-add-debian-integration-to-lighttpd.patch,
14.04-etc-writable.patch,
14.04-update-base-abstraction-for-signals-and-ptrace.patch,
14.04-dnsmasq-libvirtd-signal-ptrace.patch,
14.04-update-chromium-browser.patch,
14.04-php5-Zend_semaphore-lp1401084.patch,
14.04-dnsmasq-lxc_networking-lp1403468.patch,
14.04-profiles-texlive_font_generation-lp1010909.patch,
14.04-profiles-dovecot-updates-lp1296667.patch,
14.04-profiles-adjust_X_for_lightdm-lp1339727.patch: Import all of the
patches, from 14.04's 2.8.95~2430-0ubuntu5.3 apparmor package, which
patched profiles/ and adjust them to patch profiles-14.04/ instead.
- debian/patches/revert-r2550-and-r2551.patch: Revert two upstream changes
to mod_apparmor which could potentially regress existing users of
mod_apparmor in 14.04. These upstream changes are not appropriate for an
SRU.
-- Tyler Hicks <tyhicks at canonical.com> Wed, 30 Nov 2016 16:36:02 +0000
** Changed in: apparmor (Ubuntu Trusty)
Status: Won't Fix => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart 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 upstart package in Ubuntu:
Invalid
Status in apparmor source package in Trusty:
Fix Released
Status in upstart source package in Trusty:
Won't Fix
Status in apparmor source package in Xenial:
Fix Released
Bug description:
=apparmor and upstart 14.04 SRU=
[Impact]
A recent 16.04 kernel (4.4.0-46.67) and the lxd (2.0.5-0ubuntu1~ubuntu16.04.1) allows us to enable stacked/namespaced AppArmor policy for 14.04 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 and upstart userspace changes needed to allow the container init to load apparmor profiles during the container boot procedure.
[Test Case]
Install the latest Xenial kernel and lxd. Reboot into the new kernel and set up a new 14.04 lxd container (MUST be an unprivileged container):
$ lxc launch ubuntu-daily:14.04 t
Install apparmor from trusty-proposed (2.10.95-0ubuntu2.5~14.04.1) and
upstart from trusty-proposed (1.12.1-0ubuntu4.3) 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-t_</var/lib/lxd>//&:lxd-t_<var-lib-lxd>:///sbin/dhclient'
lxd-t_</var/lib/lxd>//&:lxd-t_<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
Verify that aa-status works inside of the container:
$ lxc exec t -- aa-status
apparmor module is loaded.
4 profiles are loaded.
4 profiles are in enforce mode.
/sbin/dhclient
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/tcpdump
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/sbin/dhclient (518)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Now, examine the output of aa-status to verify that the
/usr/sbin/tcpdump profile is loaded.
To validate the upstart change, use apparmor-profile-load to load a
profile:
$ echo "profile lp1628285-test {} " | lxc exec t -- tee /etc/apparmor.d/lp1628285-test
$ lxc exec t -- /lib/init/apparmor-profile-load lp1628285-test
$ lxc exec t -- aa-status
apparmor module is loaded.
5 profiles are loaded.
5 profiles are in enforce mode.
/sbin/dhclient
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/tcpdump
lp1628285-test
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/sbin/dhclient (518)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
$ lxc exec t -- ls /etc/apparmor.d/cache/lp1628285-test
/etc/apparmor.d/cache/lp1628285-test
Now, reboot and then run aa-status again to verify that the output is
the same (except for the process ID numbers).
It is also a good test to install ntp and cups-daemon, use aa-status
to verify that their profiles are in enforce mode and that their
processes are confined. Then reboot and use aa-status to verify the
same thing.
[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. This feature was released in Ubuntu 16.10 and 16.04 with no known serious issues so far.
IMPORTANT: There is a known regression that may be seen by users of
`lxc exec`. See bug #1641236 for details. Bug #1640868 is pre-
existing, doesn't seem to have any negative side-effects, and is not
caused by this SRU.
=apparmor 16.04 SRU=
[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
More information about the foundations-bugs
mailing list