Current feedback from Canonical:
Canonical, [31.12.20 12:16]
Philip you can build that C snippet and try to reproduce itPhilip M, [31.12.20 12:16]
will see when I get to itCanonical, [31.12.20 12:18]
i don’t think we execute a scenario with snap-confine linked to libapparmor 3.xx running on older kernels, the snapd snap is built on 16.04 such that it link with the oldest libc and thus works on all systemsCanonical, [31.12.20 12:18]
on distros such as leap there is one kernel version so there’s no risk on incompatiblilty between libapparamor and the kernel’s aa stackCanonical, [31.12.20 12:19]
that leaves only arch, manjaro and a handfull of derivatives where you can switch between the new and old kernels bu the userland stays unchangedPhilip M, [31.12.20 12:20]
[phil@development tmp]$ gcc a.c -lapparmor
[phil@development tmp]$ ./a.out
aa_getcon: Invalid argument
[phil@development tmp]$ uname -a
Linux development 5.4.85-1-MANJARO #1 SMP PREEMPT Mon Dec 21 21:38:53 UTC 2020 x86_64 GNU/LinuxCanonical, [31.12.20 12:21]
yup, and it should work on 5.9/5.10Canonical, [31.12.20 12:22]
and this is where the init of the path to read the atribute from happens in libapparmor: libraries/libapparmor/src/kernel.c · master · AppArmor / apparmor · GitLabCanonical, [31.12.20 12:23]
looks like there is a fallback but for some reason it isn’t usedPhilip M, [31.12.20 12:24]
Seems to be an apparmor issue thenCanonical, [31.12.20 12:25]
yeah,Canonical, [31.12.20 12:25]
the logic around that check is complexCanonical, [31.12.20 12:25]
maybe just too-many !
We will continue on that issue in January/February.