| 2020-04-14 01:07:53 |
Simon Déziel |
bug |
|
|
added bug |
| 2020-05-06 19:22:05 |
Simon Déziel |
apparmor (Ubuntu): status |
New |
Fix Committed |
|
| 2020-05-07 21:11:07 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2020-05-08 14:47:32 |
Sergio Durigan Junior |
apparmor (Ubuntu): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2020-05-11 02:43:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/apparmor/+git/apparmor/+merge/383686 |
|
| 2020-05-11 09:35:50 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2020-05-11 09:35:50 |
Christian Ehrhardt |
bug task added |
|
apparmor (Ubuntu Focal) |
|
| 2020-05-11 17:37:33 |
Launchpad Janitor |
apparmor (Ubuntu Focal): status |
New |
Confirmed |
|
| 2020-05-12 16:57:34 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/apparmor/+git/apparmor/+merge/383796 |
|
| 2020-05-12 18:14:24 |
Sergio Durigan Junior |
apparmor (Ubuntu Focal): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2020-05-12 18:34:35 |
Sergio Durigan Junior |
description |
# Description
On a default Focal install, systemd is used when looking up passwd and group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information.
# Steps to reproduce
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04 |
[Impact]
On a default Focal install, systemd is used when looking up passwd and group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information.
To fix
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported. They are simple and self-contained, especially two of them, whose purposes are to add the definition of the @{run} variable and then to add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the 'nameservice' profile in order to let processes access (read-only) files under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id". After thinking about the possible cases, the only possible problem I could envision was for a program that, not being able to access some of these files before, will now be able to do that and therefore exercise a part of its codebase which was not being used, possibly uncovering latent bugs in this software. But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04 |
|
| 2020-05-12 19:01:58 |
Daniel Richard G. |
bug |
|
|
added subscriber Daniel Richard G. |
| 2020-05-13 16:04:53 |
Sergio Durigan Junior |
description |
[Impact]
On a default Focal install, systemd is used when looking up passwd and group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information.
To fix
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported. They are simple and self-contained, especially two of them, whose purposes are to add the definition of the @{run} variable and then to add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the 'nameservice' profile in order to let processes access (read-only) files under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id". After thinking about the possible cases, the only possible problem I could envision was for a program that, not being able to access some of these files before, will now be able to do that and therefore exercise a part of its codebase which was not being used, possibly uncovering latent bugs in this software. But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04 |
[Impact]
On a default Focal install, systemd is used when looking up passwd and group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported. They are simple and self-contained, especially two of them, whose purposes are to add the definition of the @{run} variable and then to add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the 'nameservice' profile in order to let processes access (read-only) files under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id". After thinking about the possible cases, the only possible problem I could envision was for a program that, not being able to access some of these files before, will now be able to do that and therefore exercise a part of its codebase which was not being used, possibly uncovering latent bugs in this software. But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04 |
|
| 2020-05-14 19:31:50 |
Launchpad Janitor |
apparmor (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-05-19 17:08:36 |
Jamie Strandboge |
apparmor (Ubuntu Focal): status |
Confirmed |
In Progress |
|
| 2020-05-19 17:08:50 |
Jamie Strandboge |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-05-22 11:31:07 |
Timo Aaltonen |
apparmor (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-05-22 11:31:09 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2020-05-22 11:31:13 |
Timo Aaltonen |
tags |
|
verification-needed verification-needed-focal |
|
| 2020-05-22 16:28:08 |
Simon Déziel |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2020-05-22 18:32:34 |
Sergio Durigan Junior |
merge proposal unlinked |
https://code.launchpad.net/~sergiodj/ubuntu/+source/apparmor/+git/apparmor/+merge/383796 |
|
|
| 2020-05-27 11:05:33 |
Marco Davids |
apparmor (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-05-28 17:46:25 |
Jamie Strandboge |
apparmor (Ubuntu Focal): status |
Fix Released |
Fix Committed |
|
| 2020-06-02 20:32:07 |
Brian Murray |
tags |
verification-done verification-done-focal |
verification-needed verification-needed-focal |
|
| 2020-06-02 20:49:56 |
Simon Déziel |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2020-06-03 00:50:39 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-06-03 00:50:58 |
Launchpad Janitor |
apparmor (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-08-31 08:36:18 |
Zaszuś |
bug |
|
|
added subscriber Zaszuś |
