On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
On 5/19/26 9:57 PM, Sasha Levin wrote:
Sure, this would also work. How do you see this happening? Can we let a certain
user/pid/etc disable the allowlist if they choose to?
I don't think we should, given then we're back to square one where root
or some other user would be able to just override/bypass an LSM.
killswitch already disables itself when lockdown is active. We can easily
disable it too when one of the LSMs that cares about this is active.
[...]
How do you see this working with the allowlist?
We should look at the underlying areas where most of the CVE-like fixes
took place (these days should be more easily doable given Claude and friends)
and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
new hooks which BPF LSM can consume where you can then have a policy to reject
requests and tighten the attack surface. For example, the AF_ALG stuff you
So we could grow the LSM tentacles deeper into the kernel, and we can see where
current CVEs are happening, which I suspect is the darker corners of the kernel
(old unmaintained, rarely used code), but this definitely won't stay the case,
right? Newer and better LLMs will discover issues elsewhere, and once the low
hanging fruits are picked off of the current target subsystems, researchers
will move elsewhere. We will be dooming ourselves to an endless cat and mouse
game where we go add LSM hooks after some big security issue goes public.
One question I had here: how would we tackle security issues with BPF itself?
can already easily cover today ...
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#define AF_ALG 38
#define EPERM 1
char _license[] SEC("license") = "Dual BSD/GPL";
SEC("lsm/socket_create")
int BPF_PROG(block_af_alg, int family, int type, int protocol, int kern)
{
if (family == AF_ALG)
return -EPERM;
return 0;
}
... the problem is that distros enable and pull in all sort of crap which
then non-root could pull in via request_module() as an example; similarly
for netlink we want to have a BPF LSM policy to parse into netlink requests
and then reject based on certain attribute matching (both on our todo list)
which would have helped in case of exotic tc cls/act/qdisc modules to prevent
them to be pulled from userns. I bet there are a ton more examples once we
look further into the data.
I definitely agree that BPF is a much nicer hammer than the simple killswitch
implementation. I've actually been (privately) playing with an out of tree
killswitch that also supports BPF. I've pushed the (hacky) code I have to
https://github.com/sashalevin/killswitch , and you can see an example of a BPF
mitigation similar to the one you have above:
https://github.com/sashalevin/killswitch/blob/master/mitigations/cve-2025-21703.sh
My concern is mostly with the whitelist approach.
--
Thanks,
Sasha
