** 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_</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]
+ =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 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/~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

Reply via email to