Hello Martin, or anyone else affected, Accepted rsyslog into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/rsyslog/8.2312.0-3ubuntu9.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-noble. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: rsyslog (Ubuntu Noble) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Fix Committed 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 ] - Deploy the ubuntu release under testing in a VM - open a terminal and leave this command running: sudo dmesg -wT | grep apparmor | grep rsyslog - open another terminal to watch the syslog file: tail -f /var/log/syslog - in another terminal, run this logger command: logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE - in the affected version of rsyslog, the dmesg output should show apparmor DENIED message - in the version from proposed, no such DENIED messages should be logged - in both cases (affected, and fixed), the EMERGENCY_MESSAGE should appear in syslog [ Where problems could occur ] We are allowing rsyslog to read the contents of /run/systemd/sessions. In a normal system, we see pipes in there, which are restricted to root and 0600 and can't be read by rsyslog (which runs as non-root in ubuntu), and regular files, which are 0644 (world readable). The contents of the 0644 files are like this: # This is private data. Do not parse. UID=1000 USER=ubuntu ACTIVE=1 IS_DISPLAY=1 STATE=active REMOTE=1 LEADER_FD_SAVED=1 TYPE=tty ORIGINAL_TYPE=tty CLASS=user SCOPE=session-1.scope FIFO=/run/systemd/sessions/1.ref REMOTE_HOST=10.10.12.11 SERVICE=sshd POSITION=0 LEADER=939 AUDIT=1 REALTIME=1738348669502009 MONOTONIC=18174930 Note that "private data" in this context means that there is no guarantee of its format, not that it's secret (hence the "do not parse" warning). There is no code in rsyslog directly reading these files. This comes from the linking with the systemd library. A possible regression could be related to this data now having been read and being in memory, and being one small step in a larger sequence of exploits. [ Other Info ] Other apparmor rules are being added to rsyslog via this upload, closing other bugs: - LP: #2073628 for noble, oracular, and plucky - LP: #2061726 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 ] 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 -- 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
