** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. + 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. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + 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 + * 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. + * 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. + * 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? + * 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. + * 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 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. + * 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 + * 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. + * 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 - + * 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
** Description changed: [ 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 + - Deploy the ubuntu release under testing in a VM - * 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. + - open a terminal and leave this command running: - * if other testing is appropriate to perform before landing this - update, this should also be described here. + 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 ] * 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 -- 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: 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 ] - 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 [ 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
