sts-sponsors team mailing list archive

[Łukasz Zemczak <1717714@xxxxxxxxxxxxxxxxxx>]

Hello Andre, 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.8 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 on 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-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

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

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1717714

Title:
  @{pid} variable broken on systems with pid_max more than 6 digits

Status in AppArmor:
  Fix Committed
Status in AppArmor 2.11 series:
  Fix Committed
Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Trusty:
  Fix Committed
Status in apparmor source package in Xenial:
  Fix Committed
Status in apparmor source package in Artful:
  Fix Committed
Status in apparmor source package in Bionic:
  Fix Released
Status in apparmor package in Debian:
  Fix Released

Bug description:
  [Impact]

  If PID is larger than 6 digits apparmor denies process which only
  affect 64-bit systems[1] where the PID_MAX_LIMIT can be generated up
  to 7 digits at the maximum.

  This fix is committed, but not released. so all supporting version are
  affected.

  [1] - man 5 proc

  --------------------------------------------------------------------------
  /proc/sys/kernel/pid_max (since Linux 2.5.34)
  This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID).  PIDs greater than this value are not allocated;  thus,  the value  in this file also acts as a system-wide limit on the total number of processes and threads.  The default value for this file, 32768, results in the same range of PIDs as on ear‐lier kernels.  On 32-bit platforms, 32768 is the maximum value for pid_max.  On 64-bit systems, pid_max can be set to any value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).
  --------------------------------------------------------------------------

  [Test Case]

  1. making pid over 6 digits
  #!/bin/bash

  for i in {1..1000000}
  do
    touch t
  done

  2. snap install --dangerous core_16-2.29.4.2_amd64.snap ( snap core
  16-2.30 avoids using /proc/PID/cmdline, so need to use older version

  3. you can see DENIED msgs in syslog

  4. change /etc/apparmor.d/tunables/kernelvars
  5. service apparmor restart
  6. service snapd restart
  7. DENIED is gone

  This is one way, can't reproduce this issue again even if you change
  back to original kernelvars, and restart snapd

  OR

  instead of Seyeong's touch approach, things can be manually change to
  7 digits range via sysctl as long as the values are below
  approximately 4 millions :

  Example:
  $ sysctl -w kernel.pid_max=3000000
  $ sysctl -w kernel.ns_last_pid=1000000

  [Regression]
  * This is a minor/trivial fix which changes the pid regex only, allowing 7 digits PID instead of only 6 digits PID, we don't think there is any potential regression.

  * If a regression arise, which we highly doubt, one can quickly revert
  the change manually and restart the service by modifying
  "/etc/apparmor.d/tunables/kernelvars" file to its original state
  (before this SRU).

  [Others]

  * Upstream commit:
   https://gitlab.com/apparmor/apparmor/commit/630cb2a981cdc731847e8fdaafc45bcd337fe747
  http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3722

  * Debian bug:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886732

  * commit 630cb2a981cdc731847e8fdaafc45bcd337fe747
  Author: Vincas Dargis <vindrg@xxxxxxxxx>
  Date:   Sat Sep 30 15:28:15 2017 +0300

      Allow seven digit pid

  * Affecting releases : TXZAB
  --------------------------------------------------------------------------
  $ git describe --contains 630cb2a9
  v2.11.95~5^2

  $ rmadison apparmor
   apparmor | 2.8.95~2430-0ubuntu5       | trusty
   apparmor | 2.10.95-0ubuntu2.6~14.04.1 | trusty-security
   apparmor | 2.10.95-0ubuntu2.6~14.04.1 | trusty-updates
   apparmor | 2.10.95-0ubuntu2           | xenial
   apparmor | 2.10.95-0ubuntu2.6         | xenial-security
   apparmor | 2.10.95-0ubuntu2.7         | xenial-updates
   apparmor | 2.11.0-2ubuntu4            | zesty
   apparmor | 2.11.0-2ubuntu17           | artful
   apparmor | 2.11.0-2ubuntu18           | bionic

  $ rmadison -u debian apparmor
   apparmor | 2.11.1-4                   | unstable
  --------------------------------------------------------------------------

  [Original Description]

  If your kernel.pid_max sysctl is set higher than the default, say at 7
  digits, the @{pid} variable no longer matches all pids, causing some
  breakage in any profile using it.

  @{pid} is defined in /etc/apparmor.d/tunables:
  @{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}

  It only covers up to 6 digits.

  This Ubuntu 17.04 system has:
  kernel.pid_max = 4194303

  And is showing
  type=1400 audit(1505588857.828:792): apparmor="DENIED" operation="open" profile="libvirt-55e9e12c-e6dc-4f56-a547-8514cf7d9bf3" name="/proc/2168180/task/2769256/comm" pid=2168180 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111

  Which should be matched by
  @{PROC}/sys/vm/overcommit_memory r,
  in /etc/apparmor.d/abstractions/libvirt-qemu

  I'm seeing similar failures on 16.04 (2.10.95-0ubuntu2.7), 17.04
  (2.11.0-2ubuntu4) and 17.10 (2.11.0-2ubuntu17)

  I am aware this is a non-default configuration, but I think this
  should work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1717714/+subscriptions