Bugzilla – Bug 1205603
bpf lsm enabled but not included in LSM list
Last modified: 2024-07-10 13:49:30 UTC
During my system upgrades i noticed the following message: ```systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported``` but we have: ```CONFIG_BPF_LSM=y``` i asked Frank Bui what it checks for. it checks for the string "bpf" in this list: ``` cat /sys/kernel/security/lsm lockdown,capability,apparmor ``` it seems ```CONFIG_LSM="integrity,apparmor"``` needs an update.
The default value for this in the upstream kernel when apparmor is the default LSM: landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf
bpf was removed from the list explicitly, at commit 0a20128a486536db31e484f5848e239f8acd0fba: Revert "config: Enable BPF LSM" (bsc#1197746) This reverts commit c2c25b18721866d6211054f542987036ed6e0a50. This config change was reported to break boot if SELinux is enabled. Revert until we have a fix.
well there was more removed than just bpf :)
Not really, others haven't been added from the beginning in our config. OTOH, bpf was added once but removed later due to a regression.
I've came across the problem that YAMA is not initialized during boot. There is also no /proc/sys/kernel/yama directory because of this. It looks like yama is also missing inside the CONFIG_LSM variable. Compared to Ubuntu, where the access to the ptrace_scope switch is possible, the SUSE configuration also missing 'Landlock support' and 'kernel lockdown'. CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"
Now that the ALP kernel is branched, I've pulled the changes back in.
this seems fixed in TW
reopen in case we want to update the list also in leap/SLE
Jeff, this needs to be fixed in the ALP kernel as well (and SLE etc)? not listing selinux in SLE15 seems wrong
(In reply to Dirk Mueller from comment #12) > Jeff, this needs to be fixed in the ALP kernel as well (and SLE etc)? not > listing selinux in SLE15 seems wrong ALP kernel already changed CONFIG_LSM. Still an open question is about SLE15.
I have found out that using the default upstream value for CONFIG_LSM will cause a slight performance regression if a user removes the security= parameter from the kernel command line. Removing the security= parameter will result in the tomoyo LSM being enabled, which will cause a regression in throughput in cases where small amounts of data are transferred between processes and many syscalls are made. Please refer to bug 1212446 comment 5 for details. My recommendation for ALP: CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,bpf" My recommendation for SLES15sp6: CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,bpf"
what will be the process to ensure that we regularly evaluate if that string should be adapted again?
(In reply to Marcus Rückert from comment #17) > what will be the process to ensure that we regularly evaluate if that string > should be adapted again? There are various factors. We have seen a functional issue - the systemd warning message. The first log entries in the systemd repo that mention functionality related to the bpf LSM: > v249-1227-g184b4f78cf core: add BPF LSM functions > v249-1228-gb1994387d3 core: use LSM BPF functions to implement RestrictFileSystems= which were merged into v250-rc1. The v250 of systemd was tagged on 23rd Dec, 2021. I did not check when a version of systemd relying on the bpf LSM made it into Tumbleweed. Then, there is a possible performance issue - a regression happening after removing the security=.* parameter from the kernel command line. The processes currently in place do not guarantee that a bug or two could not slip by (but what does, really?). There are two groups of people involved: 1. As for functional issues, packagers need to be aware of the changes in requirements of the piece of software that they are updating. Packagers need to make sure the requirements are met otherwise the features that correspond to those requirements ought to be disabled during compilation. That could be considered as one process. 2. The performance team tests every kernel to be released in a product (both SLES and ALP). If there were any more performance issues with LSMs the performance team would identify them. We would basically see a dip in performance and an extra LSM callback executed in the profile (which is why I am currently commenting in this bug). That could be considered as another process. I think it is unnecessary to design a process specifically for the CONFIG_LSM option. Generally, a change of the CONFIG_LSM option would be needed if a new LSM was written or changes were made to the sematics of major LSMs and exclusive LSMs. None of this is likely to happen in the next 5 years. The dates when the current major LSMs were merged into the mainline kernel: selinux - 2000 (predates current git history), smack - 2008, tomoyo - 2009, apparmor - 2010. Perhaps, the notion of major LSMs could eventually be dropped together with the security parameter. In the case of the sematics of major LSMs being dropped, my proposed changes to the CONFIG_LSM option guarantee that the LSM settings would remain the same even if the security parameter was no longer recognized by the kernel. I checked the kernel config for ALP-current. The loadpin and safesetid LSMs are not even compiled so the CONFIG_LSM value can just become: My recommendation for ALP: CONFIG_LSM="landlock,lockdown,yama,integrity,selinux,bpf" My recommendation for SLES15sp6: CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf"
(In reply to Jiri Wiesner from comment #18) > My recommendation for SLES15sp6: > CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf" I expect the systemd version in 15sp6 may get need the bpf LSM. If that is the case CONFIG_LSM for SLES15sp6 should become just: CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"
(In reply to Jiri Wiesner from comment #19) > (In reply to Jiri Wiesner from comment #18) > > My recommendation for SLES15sp6: > > CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf" > I expect the systemd version in 15sp6 may get need the bpf LSM. If that is > the case CONFIG_LSM for SLES15sp6 should become just: > CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor" We've had one reported regression against the change to append "bpf" to Leap 15.6 CONFIG_LSM: bsc#1227282 . In evaluating how we should proceed it'd be helpful to know whether systemd in SLES/Leap 15-SP6 does actually require the bpf LSM.
(In reply to David Disseldorp from comment #24) > We've had one reported regression against the change to append "bpf" to Leap > 15.6 CONFIG_LSM: bsc#1227282 . In evaluating how we should proceed it'd be > helpful to know whether systemd in SLES/Leap 15-SP6 does actually require > the bpf LSM. well it isnt just about systemd. other tools might use it too. if the whole process is so fragile, then we should probably look into making it easier for users to enable selinux. e.g. even for a tech preview it might make sense to have selinux in the kernel lsm list there.
(In reply to Marcus Rückert from comment #25) > (In reply to David Disseldorp from comment #24) > > We've had one reported regression against the change to append "bpf" to Leap > > 15.6 CONFIG_LSM: bsc#1227282 . In evaluating how we should proceed it'd be > > helpful to know whether systemd in SLES/Leap 15-SP6 does actually require > > the bpf LSM. > > well it isnt just about systemd. other tools might use it too. Understood, it's just that this ticket (and bsc#1219440) indicate systemd as the only known consumer. > if the whole > process is so fragile, then we should probably look into making it easier > for users to enable selinux. e.g. even for a tech preview it might make > sense to have selinux in the kernel lsm list there. Given that selinux isn't a primary target for SLE15-SP6 (as opposed to SL Micro 6), I think we can just leave "bpf" there and document the lsm=selinux,bpf workaround.