On 8/28/20 12:24 PM, Jonas Große Sundrup wrote: > Hi, > > I apparently just ran into a kernel regression with AppArmor and I'm > looking for the correct bugtracker now. > > The situation at hand is roughly the following: > > /usr/bin/element-desktop > is a bash-script, therefore spawns a bash > spawns "electron /usr/lib/element/element.asar" > > I have a profile for /usr/bin/element-desktop containerizing this stack > using ix for execution. This, if I have this correctly, should spawn > every subprocess of the aforementioned executable in the same profile, > hence this should also work recursively. > I observe the problem specifically for the element-desktop-profile, I > have other AppArmor-profiles that still work as intended. > > It does work on Linux 5.8.1, but it apparently doesn't anymore on 5.8.2 > and 5.8.3, where I get a permission denied for bash for
This would point to a kernel change. Do you know how to bisect? Or are you willing to test debug kernels built for you based on a bisect. The other option is try to reproduce locally so that we can then bisect based on that. > /etc/ld.so.cache as well as /usr/lib/libreadline.so.8.0 (albeit not > changing the AppArmor-profile, and both are whitelisted for reading > (which is the permission that's denied by AppArmor according to dmesg), > one via "/usr/** rmix,", the other via "/etc/ld.so.cache mr," therefore > I am 90% sure that this is not a mistake on my side and 10% sure that > I missed something, but don't know what). > Are either these files symlinks are your system? > The bug seems to be in the "ix", as explicitly whitelisting both files > in the profile manually does not resolve the situation, at least not ix doesn't in and of it self give mmap executable permissions. You would need to have libs having the m permission which you did mention above. > for libreadline, and the process that dies on it is the bash in the > second stage. (I somehow managed to fix it for ld.so.cache, not sure why > that works whereas for libreadline it doesn't). > symlink? Another possibility is something around an inherited file descriptor for an unconfined bash. > The question now is: which bugtracker does this go to to be best > reported if it continues to be a bug? Kernel or AppArmor-Tools? You can report bugs how ever works best for you. Just report them to the ml if you want. As for bug trackers For kernel issues: https://gitlab.com/apparmor/apparmor-kernel/-/issues you could also use https://gitlab.com/apparmor/apparmor/-/issues which is the more active tracker, but is predominately used for the userspace. That said if that one works for you over the kernel specific one, feel free. You can of course use alternative bug trackers, but if you do please send some kind of message to the ml as we don't get direct notifications Ubuntu: https://bugs.launchpad.net/apparmor/ or for Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/apparmor suse: https://bugzilla.opensuse.org debian: https://bugs.debian.org or if you are sure it is the apparmor kernel component you can file it on the kernel's bugzilla, but again please message us because we do not get notifications of bugs filed there. > Seems to be the kernel, but I don't know how AppArmor is implemented, > if it's something implemented in eBPF it's possibly not the kernel? > It is not implemented in eBPF. Its an LSM module in the linux kernel with policy being built into a state machine in userspace and loaded into the kernel. The policy is flexible but (deliberately) no where near as flexible as eBPF. This provides assurances on provability, provable minimization, and consistency around caching etc. > Maybe I have another idea for the root cause, but currently I'm a bit > out of ideas. (Open for ideas, though, if anyone has a guess what's the > issue at play.) > if it worked in 5.8.1 and not 5.8.2 that really smells like a kernel issue. My immediate two suspects are the mmap code and bprm. But I need to dig more. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
