[Touch-packages] [Bug 1117804] Re: ausearch doesn't show AppArmor denial messages
Any news on this? It has been open for over ten years now. AppArmor is on by default on Ubuntu, and if auditd is used, then the events are logged using it. Isn't it a security bug if the events don't show up when queried using ausearch? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1117804 Title: ausearch doesn't show AppArmor denial messages Status in AppArmor: Confirmed Status in audit package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Bug description: The following command should display all AVC denials: ausearch -m avc However, it doesn't work with AppArmor denials. Here's a quick test case to generate a denial, search for it with ausearch, and see that no messages are displayed: $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current cat: /proc/self/attr/current: Permission denied $ sudo ausearch -m avc -c cat ausearch claims that there are no matches, but there's a matching audit message if you look in audit.log: type=AVC msg=audit(1360193426.539:64): apparmor="DENIED" operation="open" parent=8253 profile="/usr/sbin/tcpdump" name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1117804/+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
[Touch-packages] [Bug 1923377] Re: Automatically installed systemd:i386 makes graphical boot hang
Since nobody else seems to have this problem, and I managed to fix my system, I suggest that this can be closed. For the record, I suspect that the inclusion of i386 packages started with the installation of the wine package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923377 Title: Automatically installed systemd:i386 makes graphical boot hang Status in systemd package in Ubuntu: Incomplete Bug description: 1) Description: Ubuntu 20.04.2 LTS Release: 20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923377/+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
[Touch-packages] [Bug 1923377] [NEW] Automatically installed systemd:i386 makes graphical boot hang
Public bug reported: 1) Description:Ubuntu 20.04.2 LTS Release:20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Part from /var/log/apt/history.log containing the problematic update" https://bugs.launchpad.net/bugs/1923377/+attachment/5486631/+files/short-apt-history.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923377 Title: Automatically installed systemd:i386 makes graphical boot hang Status in systemd package in Ubuntu: New Bug description: 1) Description: Ubuntu 20.04.2 LTS Release: 20.04 2) systemd:i386 (245.4-4ubuntu3.6, automatic) systemd:amd64 (245.4-4ubuntu3.6, automatic) 3) I expected that letting the system install/upgrade packages it suggested would cause no harm. 4) Harm was caused. Graphical boot got stuck after the grub menu. But I could access virtual console be pressing alt-F1. I accepted the upgrade on Saturday, on Sunday, when tried to boot the machine, the machine hung up. I suspect that one of the problematic packages was systemd:i386. I have no idea why a 32bit version of this got installed, and other 32bit versions as well. I attached an excerpt from /var/log/apt/history.log showing the problematic upgrade. One of the results was that the binaries /usr/bin/systemctl and /lib/systemd/systemd were 32bit executables, and they could not load appropriate the pam modules (which were still 64bit). But as I could log in from the virtual terminal just fine, this showed that pam itself was working, systemd was the problem. After long struggle I managed to fix this by reinstalling systemd, which overwrote the above binaries with their 64bit versions. Removing systemd:i386 would have deleted systemd altogether. After that I purged various 32bit packages I suspected were causing problems. And I installed the packages removed by the upgrade on Saturday, such as snapd. Now the system boots up in graphical mode just fine. But why did the 32bit versions of systemd etc got installed automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923377/+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
