This bug was fixed in the package rsyslog - 8.2406.0-1ubuntu3
---------------
rsyslog (8.2406.0-1ubuntu3) plucky; urgency=medium
* d/usr.sbin.rsyslogd: add AppArmor rule to allow the imjournal module to
work (LP: #2073628)
* d/usr.sbin.rsyslogd: add AppArmor rule to allow access to disable_ipv6
inside /proc (LP: #2061726)
-- Andreas Hasenack <andr...@canonical.com> Fri, 31 Jan 2025 16:48:57
-0300
** Changed in: rsyslog (Ubuntu Plucky)
Status: In Progress => Fix Released
--
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/2061726
Title:
rsyslog apparmor denial on reading
/proc/sys/net/ipv6/conf/all/disable_ipv6
Status in apparmor package in Ubuntu:
Invalid
Status in rsyslog package in Ubuntu:
Fix Released
Status in apparmor source package in Noble:
Invalid
Status in rsyslog source package in Noble:
In Progress
Status in apparmor source package in Oracular:
Invalid
Status in rsyslog source package in Oracular:
In Progress
Status in apparmor source package in Plucky:
Invalid
Status in rsyslog source package in Plucky:
Fix Released
Bug description:
[ Impact ]
rsyslog has an apparmor profile that we have been fine tuning as
ubuntu releases go by. Every now and then, a new rule needs to be
added.
This case in particular isn't breaking anything as far as we can see,
but it creates noise in the logs. By itself it's not worth an SRU, but
other apparmor fixes are accumulating, and will be fixed in the same
upload.
One scenario where rsyslog was found to be blocked from accessing
/proc/sys/net/ipv6/conf/all/disable_ipv6 is when:
a) libnss-myhostname (from systemd) is installed;
b) is reached via /etc/nsswitch.conf.
Depending on the ubuntu release, the order in which myhostname inserts
itself into /etc/nsswitch.conf is different.
In Oracular and Plucky, it's:
hosts: files myhostname dns
In Noble, it's:
hosts: files dns myhostname
For the test plan, we will make sure myhostname is reached.
The reason rsyslog is affected by this, is because the nss module is
loaded into the process's space, and libsystemd as well, and that's
where the code reaching out to disable_ipv6 is.
[ Test Plan ]
- Deploy the ubuntu release under test in a VM
- install libnss-myhostname
sudo apt install libnss-myhostname
- make sure the hosts line in /etc/nsswitch.conf has myhostname after
files and before dns, like this:
hosts: files myhostname dns
- open a terminal with dmesg, running like this:
dmesg -wT | grep apparmor | grep rsyslog
- in another terminal, restart rsyslog:
sudo systemctl restart rsyslog
- in an affected system, there will be an apparmor DENIED message in
the dmesg output:
apparmor="DENIED" operation="open" class="file" profile="rsyslogd"
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=2514
comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
- in a system with the updated rsyslog package from proposed
installed, there will be no such DENIED message
[ Where problems could occur ]
Everytime an apparmor rule is added, one has to wonder about the
security implications. Or, if it's a new rule blocking something, what
else could go wrong.
In this case, we are allowing read access to the disable_ipv6 /proc
file, which just tells whether ipv6 was disabled for all interfaces or
not. Before rsyslog (via libsystemd) was blocked from reading this
file, and nothing else bad happened that we could see. Now, reading
will be allowed, and maybe the code will take some decision based on
what it reads, and this could have other consequences. Maybe it would
try to write to it, but since rsyslog runs as non-root, that would
already not be allowed, regardless of apparmor rules.
There is no "disable_ipv6" string match in the rsyslog code: this
comes entirely from systemd. There is this bit in the systemd NEWS
file:
* systemd-networkd's handling of the kernel's disable_ipv6 sysctl is
simplified: systemd-networkd will disable the sysctl (enable IPv6) if
IPv6 configuration (static or DHCPv6) was found for a given
interface. It will not touch the sysctl otherwise.
So there is a case for systemd-networkd writing to that file, but
that's the systemd-networkd daemon, not just the library making some
decision. And that would be blocked if rsyslog were to attempt that,
as it doesn't run as root.
[ Other Info ]
Other apparmor rules are being added to rsyslog via this upload, closing
other bugs:
- LP: #2056768 for noble only
- LP: #2073628 for noble, oracular, and plucky
[ Original Description ]
One of our Cockpit integration tests [1] spotted an AppArmor
regression in rsyslogd. This is coincidental, the test passes and it
doesn't do anything with rsyslogd -- just something happens to happen
in the background to trigger this (and I can actually reproduce it
locally quite reliably).
Mar 08 10:48:20 m1.cockpit.lan systemd[1]: dpkg-db-backup.service:
Deactivated successfully.
Mar 08 10:48:20 m1.cockpit.lan systemd[1]: Finished dpkg-db-backup.service -
Daily dpkg database backup service.
Mar 08 10:48:20 m1.cockpit.lan systemd[1]: rsyslog.service: Sent signal
SIGHUP to main process 752 (rsyslogd) on client request.
Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400
audit(1615200500.418:125): apparmor="DENIED" operation="open" class="file"
profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752
comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0
Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400
audit(1615200500.418:126): apparmor="DENIED" operation="open" class="file"
profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752
comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0
This happens on current Ubuntu 24.04 LTS noble devel, rsyslog
8.2312.0-3ubuntu8 and apparmor 4.0.0-beta3-0ubuntu3.
[1]
https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/log.html#152
[2]
https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/TestHistoryMetrics-testEvents-ubuntu-stable-127.0.0.2-2901-FAIL.log.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2061726/+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
