[Bug 2056768] Re: apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/"

Fri Jan 31 20:27:08 UTC 2025

** Description changed:

+ [ Impact ]
+ 
+  * An explanation of the effects of the bug on users and justification
+    for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+    explanation of how the upload fixes this bug.
+ 
+ [ Test Plan ]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package
+    fixes the problem.
+ 
+  * if other testing is appropriate to perform before landing this
+    update, this should also be described here.
+ 
+ [ Where problems could occur ]
+ 
+  * Think about what the upload changes in the software. Imagine the
+    change is wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the event
+    of a regression.
+ 
+  * This must never be "None" or "Low", or entirely an argument as to why
+    your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
+ 
+ [ Other Info ]
+ 
+  * Anything else you think is useful to include
+ 
+  * Make sure to explain any deviation from the norm, to save the SRU
+    reviewer from having to infer your reasoning, possibly incorrectly.
+    This should also help reduce review iterations, particularly when the
+    reason for the deviation is not obvious.
+ 
+  * Anticipate questions from users, SRU, +1 maintenance, security teams
+    and the Technical Board and address these questions in advance
+ 
+ 
+ [ Original Description ]
+ 
  There is an AppArmor regression in current noble. In cockpit we recently
  started to test on noble (to prevent the "major regressions after
  release" fiasco from 23.10 again).

  For some weird reason, rsyslog is installed *by default* [1] in the
  cloud images. That is a rather pointless waste of CPU and disk space, as
  it's an unnecessary running daemon and duplicates all the written logs.

  But more specifically, we noticed [2] an AppArmor rejection. Reproducer
  is simple:

-     logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE
+     logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE

  this causes

-     type=1400 audit(1710168739.345:108): apparmor="DENIED"
+     type=1400 audit(1710168739.345:108): apparmor="DENIED"
  operation="open" class="file" profile="rsyslogd"
  name="/run/systemd/sessions/" pid=714 comm=72733A6D61696E20513A526567
  requested_mask="r" denied_mask="r" fsuid=102 ouid=0

  Note that it doesn't actually fail, the "EMERGENCY_MESSAGE" does appear
  in the journal and also in /var/log/syslog. But it's some noise that
  triggers our (and presumbly other admin's) log detectors.

- 
  rsyslog 8.2312.0-3ubuntu3
  apparmor 4.0.0~alpha4-0ubuntu1

- 
  [1] https://cloud-images.ubuntu.com/daily/server/noble/current/noble-server-cloudimg-amd64.manifest
  [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-6048-20240311-125838-b465e9b2-ubuntu-stable-other-cockpit-project-cockpit/log.html#118

-- 
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/2056768

Title:
  apparmor="DENIED" operation="open" class="file" profile="rsyslogd"
  name="/run/systemd/sessions/"

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Noble:
  In Progress

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.

  By virtue of being linked with systemd, some log messages will trigger
  reading /run/systemd/sessions, and this is currently not allowed by
  the apparmor profile.

  Even with the denial, the log message still makes its way through to
  the journal and other logs, but the apparmor DENIED message is noisy.

  Upstream was initially contacted about this interaction with systemd,
  but the conversation stalled (there doesn't seem to be a current
  archive for rsyslog-users, otherwise I would have linked the
  conversation here).

  [ Test Plan ]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package
     fixes the problem.

   * if other testing is appropriate to perform before landing this
     update, this should also be described here.

  [ Where problems could occur ]

   * Think about what the upload changes in the software. Imagine the
     change is wrong or breaks something else: how would this show up?

   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the event
     of a regression.

   * This must never be "None" or "Low", or entirely an argument as to why
     your upload is low risk.

   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.

  [ Other Info ]

   * Anything else you think is useful to include

   * Make sure to explain any deviation from the norm, to save the SRU
     reviewer from having to infer your reasoning, possibly incorrectly.
     This should also help reduce review iterations, particularly when the
     reason for the deviation is not obvious.

   * Anticipate questions from users, SRU, +1 maintenance, security teams
     and the Technical Board and address these questions in advance

  [ Original Description ]

  There is an AppArmor regression in current noble. In cockpit we
  recently started to test on noble (to prevent the "major regressions
  after release" fiasco from 23.10 again).

  For some weird reason, rsyslog is installed *by default* [1] in the
  cloud images. That is a rather pointless waste of CPU and disk space,
  as it's an unnecessary running daemon and duplicates all the written
  logs.

  But more specifically, we noticed [2] an AppArmor rejection.
  Reproducer is simple:

      logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE

  this causes

      type=1400 audit(1710168739.345:108): apparmor="DENIED"
  operation="open" class="file" profile="rsyslogd"
  name="/run/systemd/sessions/" pid=714 comm=72733A6D61696E20513A526567
  requested_mask="r" denied_mask="r" fsuid=102 ouid=0

  Note that it doesn't actually fail, the "EMERGENCY_MESSAGE" does
  appear in the journal and also in /var/log/syslog. But it's some noise
  that triggers our (and presumbly other admin's) log detectors.

  rsyslog 8.2312.0-3ubuntu3
  apparmor 4.0.0~alpha4-0ubuntu1

  [1] https://cloud-images.ubuntu.com/daily/server/noble/current/noble-server-cloudimg-amd64.manifest
  [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-6048-20240311-125838-b465e9b2-ubuntu-stable-other-cockpit-project-cockpit/log.html#118

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2056768/+subscriptions