** Description changed:

  [ Impact ]
  
  The unprivileged_userns profile did not grant access to the root
  directory, which was an oversight in a profile that is intended to allow
  almost all accesses except for capabilities usage. This would e.g. break
  listing of the root directory contents from a user namespace.
  
  [ Test Plan ]
  
  After installation of the new AppArmor version:
-  * Ensure that the sysctl kernel.apparmor_restrict_unprivileged_unconfined is 
set to 1
-  * Run unshare -U ls / and verify that it lists the directory successfully 
without creating an AppArmor denial log
+  * Ensure that the sysctl kernel.apparmor_restrict_unprivileged_unconfined is 
set to 1
+  * Run `sudo aa-status` and verify that an unprivileged_userns profile is 
loaded
+  * Run unshare -U ls / and verify that it lists the directory successfully 
without creating an AppArmor denial log
  
  [ Where problems could occur ]
  
  Changing the rule to allow access to the root directory is loosening
  confinement on the profile. However, if a user manually modified the
  installed profiles, then the package upgrade would cause conflicts, and
  rejection of the incoming changes (either by hand during an interactive
  upgrade or automatically during an batch unattended upgrade) would
  result in end users not getting this fix.
  
  [ Other Info ]
  
  This bug was originally reported at
  https://gitlab.com/apparmor/apparmor/-/issues/505.

-- 
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/2110616

Title:
  apparmor unprivileged_userns profile missing access to /

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Plucky:
  In Progress
Status in apparmor source package in Questing:
  Fix Released

Bug description:
  [ Impact ]

  The unprivileged_userns profile did not grant access to the root
  directory, which was an oversight in a profile that is intended to
  allow almost all accesses except for capabilities usage. This would
  e.g. break listing of the root directory contents from a user
  namespace.

  [ Test Plan ]

  After installation of the new AppArmor version:
   * Ensure that the sysctl kernel.apparmor_restrict_unprivileged_unconfined is 
set to 1
   * Run `sudo aa-status` and verify that an unprivileged_userns profile is 
loaded
   * Run unshare -U ls / and verify that it lists the directory successfully 
without creating an AppArmor denial log

  [ Where problems could occur ]

  Changing the rule to allow access to the root directory is loosening
  confinement on the profile. However, if a user manually modified the
  installed profiles, then the package upgrade would cause conflicts,
  and rejection of the incoming changes (either by hand during an
  interactive upgrade or automatically during an batch unattended
  upgrade) would result in end users not getting this fix.

  [ Other Info ]

  This bug was originally reported at
  https://gitlab.com/apparmor/apparmor/-/issues/505.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2110616/+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

Reply via email to