Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled
Hi
On Mon, Jan 20, 2025 at 01:06:00PM +0100, Guido Berhoerster wrote:
> Am 17.01.25 um 19:16 schrieb Bastian Blank:
> > Control: tags -1 upstream
> > Controm: forwarded -1 https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> >
> > On Thu, Jan 16, 2025 at 02:16:18PM +0100, Guido Berhoerster wrote:
> >> From my superficial reading of the code the error seems to come from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313
> >
> > Yes, it does.
> >
> >> It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a filesystem path name is missing from the upstream kernel and is only enabled as a side effect of a patch distributed with AppArmor: https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> >> Ubuntu kernels contain a rebased variant of the patch which is likely why SO_PEERSEC works on Ubuntu.
> >
> > This comes from the addition of apparmor_unix_stream_connect. Without
> > it the peer context is never set.
> >
> >> The reason I stumbled on this issue is that we (ubports-team) are currently packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the DBus daemon to get the AppArmor profile of a process requesting to export a file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps running on Debian.
> >
> > So someone needs to properly submit this support upstream.
>
> >From my understanding the AppArmor project has kept this as an out-of-tree
> patch because it will have to be reworked when/if LSM stacking lands
> (see [1]). I don't follow kernel development closely but LSM-stacking has
> been under discussion for more than a decade now with no end in sight.
> Would you consider including this patch into Debian? The patch itself is
> very likely to be maintained by Ubuntu as they also make use of SO_PEERSEC.
WE had a short discussion on that in our team. BAsically, we won't
pick a change which is not going to land in upstream. That means the
support needs to go upstream in one or the other acceptable form from
Apparmor upstream.
I see and understand the problem you mention that in the related work
upstream there is ongoing discussion since years.
Regards,
Salvatore
Reply to: