[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhTB-obhgEM3g0VagzNaRUaF_tWTDu1FmX7SHeVU4pwfOA@mail.gmail.com>
Date: Fri, 6 Nov 2026 10:13:10 -0500
From: Paul Moore <paul@...l-moore.com>
To: Nakashima Seiichi <s-nakashima@....biglobe.ne.jp>
Cc: kernel-hardening@...ts.openwall.com, keescook@...nel.org, mic@...ikod.net,
linux-security-module@...r.kernel.org
Subject: Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack
surface reduction for the post-AI-CVE era
On Fri, Nov 6, 2026 at 6:15 AM Nakashima Seiichi
<s-nakashima@....biglobe.ne.jp> wrote:
>
> Hi,
>
> This is an idea I've been thinking about as a Linux user
> who has seen the CVE flood firsthand.
> I don't have the kernel development skills to implement this,
> so I'm posting it here for feedback from people who do.
>
> (This RFC was drafted with the help of Sakana AI's Namazu assistant.)
...
> 2. The idea: Kernel API Firewall (kaf)
>
> Instead of whack-a-mole with individual CVEs, restrict the *classes* of
> kernel APIs that unprivileged processes can invoke.
>
> Key insight: many kernel CVEs require specific subsystems to be
> reachable.
> If we can restrict access to dangerous kernel APIs at runtime, we can
> mitigate entire vulnerability classes without waiting for patches.
>
> 3. What kaf would look like
>
> Not syscall-level filtering (seccomp already does that). Subsystem-
> level
> semantic restrictions:
>
> - bpf: disallow BPF_PROG_LOAD for unprivileged users entirely
> - module: disallow init_module/finit_module after early boot
> - kexec: always forbidden for non-root, even with CAP_SYS_BOOT
> - ptrace: restrict to same UID or explicit allowlist
> - userfaultfd: disable by default (historical exploitation vector)
> - perf_event_open: restrict to specific events, disable hardware PMC
> - io_uring: restrict ring size, disable specific opcodes
> - namespace: restrict unshare of specific namespaces
>
> These are semantic restrictions on kernel subsystems that multiple
> syscalls may touch -- not individual syscall filters.
It should be possible to do most, if not all, of these things with an
LSM. Wearing my SELinux hat, I can say that SELinux currently
provides access controls for most of these things today. I would
expect similar capabilities with the BPF LSM, although I can't speak
to the coverage of any specific BPF LSM tools. I believe AppArmor and
Smack cover some of these things, but I can't say for certain.
--
paul-moore.com
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
