[Bug 2061726] Re: rsyslog apparmor denial on reading /proc/sys/net/ipv6/conf/all/disable_ipv6

Wed Apr 2 17:44:28 UTC 2025

I think rsyslog is ready to be released to both oracular-updates and
noble-updates.

I have confirmed that the test plans were performed correctly, the
package built on all arches, and there are no autopkgtest regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsyslog 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:
  Fix Committed
Status in apparmor source package in Oracular:
  Invalid
Status in rsyslog source package in Oracular:
  Fix Committed
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

  IMPORTANT: this upload can only be accepted after gzip from
  https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/2083700 is also
  accepted and published, otherwise rsyslog will FTBFS on s390x.

  [ 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