[Group.of.nepali.translators] [Bug 1628285] Re: apparmor should be allowed to start in containers

[Tyler Hicks]

This bug will not be fixed in 14.04, meaning that AppArmor policy will
not be loaded inside of 14.04 LXD containers and snaps will not work
inside of 14.04 LXD containers. 16.04 LXD containers should be used in
such use cases.

** Changed in: apparmor (Ubuntu Trusty)
   Status: Incomplete => Won't Fix

** Changed in: upstart (Ubuntu Trusty)
   Status: Incomplete => Won't Fix

** Changed in: upstart (Ubuntu Trusty)
 Assignee: Tyler Hicks (tyhicks) => (unassigned)

** Changed in: apparmor (Ubuntu Trusty)
 Assignee: Tyler Hicks (tyhicks) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Won't Fix
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_//&:lxd-t_:///sbin/dhclient'
  lxd-t_//&:lxd-t_:///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 

[Group.of.nepali.translators] [Bug 1628285] Re: apparmor should be allowed to start in containers

[Tyler Hicks]

** Also affects: apparmor (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: apparmor (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: apparmor (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: apparmor (Ubuntu Trusty)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Also affects: upstart (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: upstart (Ubuntu Xenial)

** Changed in: upstart (Ubuntu)
   Status: New => Invalid

** Changed in: upstart (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: upstart (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: upstart (Ubuntu Trusty)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Description changed:

+ =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_//&:lxd-x_:///sbin/dhclient'
  lxd-x_//&:lxd-x_:///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]
+ =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.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  In Progress
Status in upstart source package in Trusty:
  In Progress
Status in apparmor source package in Xenial:
  Fix Released

Bug 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 

[Group.of.nepali.translators] [Bug 1628285] Re: apparmor should be allowed to start in containers

[Launchpad Bug Tracker]

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   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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_//&:lxd-x_:///sbin/dhclient'
  lxd-x_//&:lxd-x_:///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/~group.of.nepali.translators
Post to : 

[Group.of.nepali.translators] [Bug 1628285] Re: apparmor should be allowed to start in containers

[Martin Pitt]

Hello Stéphane, or anyone else affected,

Accepted apparmor into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.5 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Also affects: apparmor (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: apparmor (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Committed

Bug 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp