** 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 ] - Deploy the ubuntu release under testing in a VM - open a terminal and leave this command running: - sudo dmesg -wT | grep apparmor | grep rsyslog + sudo dmesg -wT | grep apparmor | grep rsyslog - open another terminal to watch the syslog file: - tail -f /var/log/syslog + tail -f /var/log/syslog - in another terminal, run this logger command: - logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE + 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? + 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 - * 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. + 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). - * 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. + 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 large sequence of exploits. [ 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 - + 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
** 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 ] - 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 large sequence of exploits. + 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 -- 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
