Recently I have been testing apparmor process isolation and came across different behaviors in regards to socket isolation, especially in regards to socket file path filtering. >From what I have gathered, the documented features in apparmor are only >enforced with a kernel fully patched with all apparmor features, like what >ubuntu implements. Which means that all other linux distributions out there are currently not providing any effective process isolation through apparmor since escape path like socket communication is wide open. (the base abstraction commonly +included allows sockets and there is no file path filter implemented in distro kernels other then ubuntu) If I understand it correctly, the recently added aa patches for linux 6.17 will bring this feature for everyone but I would like to know if this is actually the correct assumption and if starting with kernel 6.17 the +upstream linux kernel actually does include all required patches to provide effective isolation. Perhaps someone could point out where the differences between upstream kernel and ubuntus/apparmor kernel are documented?
During my dive into apparmor I also noticed two possible bugs or at least strange behaviors that I wanted to point out/have checked: 1. If a profile has an include statement like: include <abstractions/base> and the profile is edited to comment out this line with a single # like this: #include <abstractions/base> then the single # is ignored and the include is interpreted anyway. Only when several ## are put before the include or there is a space in between will the line be effectively commented out. Is this intentional? 2. Even in a profile that does not have any file system permissions in a specific path, it is possible to list the file information of specific files. For example, if a profile includes: deny /home/** r, and has no other permission for this path or any subdirectories I can still do: /usr/bin/ls -l /home/tester/.ssh/id_ed25519_private_key -rw------- 1 tester tester 505 Mar 25 17:32 /home/tester/.ssh/id_ed25519_private_key >From my understanding of apparmor, this should result in a permission denied >error, but even on ubuntu it works If I now try to access the file: /usr/bin/touch /home/tester/.ssh/id_ed25519_private_key This also succeeds in updating the metadata -rw------- 1 tester tester 505 Aug 10 12:02 /home/tester/.ssh/id_ed25519_private_key Im not sure there is any critical use case to exploit this, but at the very least it allows to probe for the existance of any file in the filesystem without aa permissions and reveal its metadata, which seems to contradict +the MAC model. Thank you
