[apparmor] Kernel-regression?

[John Johansen]

On 9/5/20 2:23 AM, John Johansen wrote:
> 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.

Oops, missed reply to this. Yes ix should force the profile to be inherited
however only if its the most specific rule to match.

Eg. Your profile has
/usr/**   rmix,

and
/usr/lib/element/app.asar rmpx,

the rule
/usr/lib/element/app.asar rmpx,

is a more specific match so in this case it will be used instead of ix for
/usr/lib/element/app.asar.


Now the other place you can run into issues with profiles and ix not
passing on its profile is launchers. A launcher might have a completely
different profile or even be unconfined.

The launcher's profile will determine what confinement an application
launched by it will have.  So in this case app.asar could launch an
application under a different profile than /usr/bin/element-desktop

Also be aware that launchers that run as a daemon and use message passing.
To request an application launch, will launch applications under an
entirely different section of the process tree, and again the launchers
confinement will determine the profile of the launched application.
The only difference is this style of launcher may not even have a px
rule, but just some unix, network rules.


>> 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.
> 
> 
>