group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #20723
[Bug 1717714] Re: @{pid} variable broken on systems with pid_max more than 6 digits
** Description changed:
[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
[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).
+
+ * 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.
** Bug watch added: Debian Bug tracker #886732
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886732
** Also affects: apparmor (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886732
Importance: Unknown
Status: Unknown
--
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/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:
Confirmed
Status in apparmor source package in Trusty:
New
Status in apparmor source package in Xenial:
New
Status in apparmor source package in Zesty:
New
Status in apparmor source package in Artful:
New
Status in apparmor source package in Bionic:
Confirmed
Status in apparmor package in Debian:
Unknown
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
[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
