[apparmor] Kernel-regression?

[John Johansen]

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.