[Bug 2138270] Re: Regression related to LSM parameter ordering between bpf and apparmor modules

Keith,

After discussing with the AppArmor team, apparmor needs exclusive access
to security_socket_getpeersec_stream(), which is why the function
returns on the first LSM hook for apparmor. Giving other LSMs access
here will disable dbus mediation and could break the boot.


j-c

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2138270

Title:
Regression related to LSM parameter ordering between bpf and apparmor
modules

Status in linux package in Ubuntu:
New
Status in linux-azure-nvidia-6.14 package in Ubuntu:
New
Status in linux source package in Noble:
New
Status in linux-azure-nvidia-6.14 source package in Noble:
New
Status in linux source package in Questing:
New
Status in linux-azure-nvidia-6.14 source package in Questing:
New

Bug description:
Package: linux-azure-nvidia-6.14
Version: 6.14.0-1007.7

Summary:
When placing the bpf module ahead of the apparmor module in the LSM list (accessible via /sys/kernel/security/lsm), applications that use getsockopt(SO_PEERSEC) on Unix sockets return ENOPROTOOPT (errno 92).

Impact:
This issue surfaced when the D-Bus AppArmor integration failed with errors like:

"Failed to get AppArmor confinement information of socket peer:
Protocol not available"

The issue appears to impact any application using SO_PEERSEC for peer
authentication.

Root cause:
This issue is caused by a bug in the security_socket_getpeersec_stream() function in security/security.c. If the bpf LSM hook is called before the apparmor module, the bpf stub returns ENOPROTOOPT. Because security_socket_getpeersec_stream() returns on the first LSM hook result instead of checking for the default value (-ENOPROTOOPT) and continuing on to the next hook. When the apparmor module is moved before the bpf module in the LSM list, the label for the socket is returned properly.

The issue appears to have been fixed in this patch that hasn't been
ported to the 6.14 kernel running in noble:

https://git.launchpad.net/~ubuntu-
kernel/ubuntu/+source/linux/+git/noble/commit/?id=5a287d3d2b9de2b3e747132c615599907ba5c3c1

The changelog for the linux-azure-nvidia-6.14 kernel indicates that
the kernel is based on the 25.04 kernel. This kernel did not have the
patch from noble applied to it:

https://git.launchpad.net/~ubuntu-
kernel/ubuntu/+source/linux/+git/plucky/tree/security/security.c#n4760

How to reproduce the issue:
* Boot with lsm=bpf,apparmor,... on the affected kernel.
* Run busctl. There should be an error similar to "Failed to list names: Transport endpoint is not connected." The dbus.service log output should show AppArmor-related errors similar to "Unable to set up new connection: Failed to get AppArmor confinement information of socket peer: Protocol not available."
* Change the boot parameters so that lsm=apparmor,bpf,...
* Rerun the test. busctl should function correctly and the AppArmor-related errors in the dbus.service log should no longer be present.

Ask:
Please apply the changes from commit 5a287d3d2b9de2b3e747132c615599907ba5c3c1 (posted above) to the linux-azure-nvidia-6.14 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138270/+subscriptions