/proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Fix Released
|
Undecided
|
Sergio Durigan Junior | ||
Focal |
Fix Released
|
Undecided
|
Sergio Durigan Junior |
Bug 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(158682545
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=
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile=
Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following:
audit: type=1400 audit(158682607
audit: type=1400 audit(158682607
audit: type=1400 audit(158682607
audit: type=1400 audit(158682607
audit: type=1400 audit(158682607
[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/
[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://
100 /var/lib/
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
Related branches
- Christian Ehrhardt (community): Approve
- Steve Beattie (community): Approve
- Canonical Server: Pending requested
- Canonical Server Core Reviewers: Pending requested
-
Diff: 169 lines (+124/-0)6 files modifieddebian/apparmor.install (+1/-0)
debian/changelog (+14/-0)
debian/patches/series (+3/-0)
debian/patches/upstream-commit-1f319c3870-abstractions-nameservice-allow-accessing-run-systemd-user.patch (+37/-0)
debian/patches/upstream-commit-454fca7-Add-run-variable.patch (+47/-0)
debian/patches/upstream-commit-ef591a67-Add-trailing-slash-to-the-run-variable-definition.patch (+22/-0)
Changed in apparmor (Ubuntu Focal): | |
assignee: | nobody → Sergio Durigan Junior (sergiodj) |
description: | updated |
description: | updated |
Changed in apparmor (Ubuntu Focal): | |
status: | Fix Committed → Fix Released |
tags: |
added: verification-done verification-done-focal removed: verification-needed verification-needed-focal |
On all my machines and using various daemons, the denial messages always have fsuid==ouid. As such, I believe it would be OK to use the 'owner' specifier like this:
owner @{PROC} /sys/kernel/ random/ boot_id r,