| 2016-09-27 21:15:25 |
Stéphane Graber |
bug |
|
|
added bug |
| 2016-09-27 21:15:32 |
Stéphane Graber |
apparmor (Ubuntu): importance |
Undecided |
High |
|
| 2016-09-27 21:15:35 |
Stéphane Graber |
tags |
|
lxd |
|
| 2016-09-27 21:15:43 |
Stéphane Graber |
bug |
|
|
added subscriber Ubuntu containers team |
| 2016-09-27 23:18:45 |
Tyler Hicks |
apparmor (Ubuntu): status |
New |
Incomplete |
|
| 2016-09-27 23:42:19 |
Stéphane Graber |
apparmor (Ubuntu): status |
Incomplete |
New |
|
| 2016-09-28 15:40:22 |
Tyler Hicks |
apparmor (Ubuntu): status |
New |
In Progress |
|
| 2016-09-28 15:40:24 |
Tyler Hicks |
apparmor (Ubuntu): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-09-28 17:38:05 |
Launchpad Janitor |
branch linked |
|
lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain |
|
| 2016-09-30 23:24:46 |
Tyler Hicks |
apparmor (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2016-10-02 07:15:02 |
Launchpad Janitor |
apparmor (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-10-13 13:56:20 |
Martin Pitt |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-10-13 13:56:20 |
Martin Pitt |
bug task added |
|
apparmor (Ubuntu Xenial) |
|
| 2016-10-13 13:56:43 |
Martin Pitt |
apparmor (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2016-10-13 13:56:45 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-10-13 13:56:47 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2016-10-13 13:56:50 |
Martin Pitt |
tags |
lxd |
lxd verification-needed |
|
| 2016-10-27 04:00:20 |
Tyler Hicks |
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. |
[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:
$ 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. |
|
| 2016-10-27 04:00:50 |
Tyler Hicks |
apparmor (Ubuntu Xenial): status |
Fix Committed |
In Progress |
|
| 2016-10-27 04:00:52 |
Tyler Hicks |
apparmor (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2016-10-27 04:00:56 |
Tyler Hicks |
apparmor (Ubuntu Xenial): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-10-27 04:01:03 |
Tyler Hicks |
tags |
lxd verification-needed |
lxd verification-done |
|
| 2016-10-27 04:01:30 |
Tyler Hicks |
apparmor (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-10-27 14:38:26 |
Tyler Hicks |
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:
$ 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. |
[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. |
|
| 2016-10-27 15:26:54 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-10-27 15:26:50 |
Launchpad Janitor |
apparmor (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-11-11 23:26:01 |
Tyler Hicks |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-11-11 23:26:01 |
Tyler Hicks |
bug task added |
|
apparmor (Ubuntu Trusty) |
|
| 2016-11-11 23:26:17 |
Tyler Hicks |
apparmor (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2016-11-11 23:26:17 |
Tyler Hicks |
apparmor (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-11-11 23:26:17 |
Tyler Hicks |
apparmor (Ubuntu Trusty): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-11-11 23:26:33 |
Tyler Hicks |
bug task added |
|
upstart (Ubuntu) |
|
| 2016-11-11 23:26:48 |
Tyler Hicks |
bug task deleted |
upstart (Ubuntu Xenial) |
|
|
| 2016-11-11 23:26:56 |
Tyler Hicks |
upstart (Ubuntu): status |
New |
Invalid |
|
| 2016-11-11 23:27:03 |
Tyler Hicks |
upstart (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-11-11 23:27:06 |
Tyler Hicks |
upstart (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2016-11-11 23:27:08 |
Tyler Hicks |
upstart (Ubuntu Trusty): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-11-11 23:27:48 |
Tyler Hicks |
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. |
=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. |
|
| 2016-11-11 23:57:50 |
Tyler Hicks |
description |
=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. |
=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 #1641243 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. |
|
| 2016-11-12 18:36:02 |
Steve Langasek |
apparmor (Ubuntu Trusty): status |
In Progress |
Incomplete |
|
| 2016-11-12 18:39:40 |
Steve Langasek |
upstart (Ubuntu Trusty): status |
In Progress |
Incomplete |
|
| 2016-11-30 01:11:18 |
Tyler Hicks |
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 #1641243 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. |
=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. |
|
| 2016-12-01 21:28:45 |
Tyler Hicks |
apparmor (Ubuntu Trusty): status |
Incomplete |
Won't Fix |
|
| 2016-12-01 21:28:48 |
Tyler Hicks |
upstart (Ubuntu Trusty): status |
Incomplete |
Won't Fix |
|
| 2016-12-01 21:28:51 |
Tyler Hicks |
upstart (Ubuntu Trusty): assignee |
Tyler Hicks (tyhicks) |
|
|
| 2016-12-01 21:28:53 |
Tyler Hicks |
apparmor (Ubuntu Trusty): assignee |
Tyler Hicks (tyhicks) |
|
|
| 2017-01-18 17:28:28 |
Launchpad Janitor |
apparmor (Ubuntu Trusty): status |
Won't Fix |
Fix Released |
|
