[<prev] [next>] [day] [month] [year] [list]
Message-ID: <42f1d45c2cd4c3000dc809cd311b948fe7e520b1.camel@kjb.biglobe.ne.jp>
Date: Sun, 08 Nov 2026 06:15:28 +0900
From: Nakashima Seiichi <s-nakashima@....biglobe.ne.jp>
To: kernel-hardening@...ts.openwall.com
Cc: keescook@...omium.org, paul@...l-moore.com, mic@...ikod.net
Subject: [RFC v2] Kernel API Firewall (kaf): emergency CVE mitigation via
loadable policy modules
Hi all,
Thank you to Paul Moore and others who responded to the initial RFC.
Based on that feedback, I have refined the scope and design direction.
This v2 focuses specifically on kaf as an *emergency mitigation
mechanism* rather than a general-purpose security boundary.
(Note: This RFC was drafted with assistance from Sakana AI's Namazu
assistant. Technical details are sketches for discussion, not
implementation proposals. I am not a kernel developer and seek
design direction from those who are.)
1. Refined scope: what kaf is and is not
kaf is NOT:
- a replacement for seccomp, LSMs, or other access control
- a permanent security boundary
- a mechanism for general syscall filtering
kaf IS:
- an emergency attack-surface reduction mechanism
- active only during the "patch gap" between CVE disclosure
and distro patch availability
- a way to block specific vulnerable code paths without waiting
for a full kernel update
2. Motivation: why this matters now
The patch gap is the critical problem:
upstream fixes: 24-48 hours
distro backports: 30-90 days (some variants longer)
user exposure: the entire gap
For example, a container host running Ubuntu 24.04's GA kernel
may wait weeks for a critical CVE backport. During that time,
users currently have no kernel-level mitigation available.
kaf aims to give distros a mechanism to ship *temporary, targeted
mitigations* that can be loaded and unloaded without a full kernel
upgrade.
3. Proposed architecture: three layers
Layer 1: Kernel stub hooks (minimal, permanent)
- Small #ifdef CONFIG_KAF stubs in target subsystems
(bpf, module, kexec, ptrace, io_uring, net/ipv4, etc.)
- When disabled, cost is near-zero via static_branch_unlikely
- When enabled, calls into Layer 2
Layer 2: kaf.ko (LKM, CONFIG_KAF=M capable)
- Framework for managing and invoking Layer 3 policies
- Loaded/unloaded by the distro as needed
- No policy logic itself; delegates to eBPF programs
Layer 3: kaf-policy-cve-XXXX.o (eBPF programs)
- One eBPF program per CVE or vulnerability class
- Distro ships these as emergency packages
- Example lifecycle:
CVE discovered on Monday
distro ships kaf-policy-cve-2026-99999 on Tuesday
kernel 7.0.0-43 fixes it next month
policy is unloaded and package removed
4. Example lifecycle
Normal state:
- kaf stubs are present but inactive
- kaf.ko is not loaded, or loaded with no policies
Emergency state:
- Distro loads kaf-policy-cve-2026-99999.o via kaf.ko
- Specific vulnerable code path is blocked
- Audit logs record blocked attempts
Resolved state:
- Kernel update ships with proper fix
- Policy is unloaded and package removed
- System returns to normal state
5. Why existing mechanisms are insufficient for this use case
Paul Moore correctly noted that SELinux (and BPF LSM) can cover
much of this territory. However, the emergency mitigation use
case has specific requirements that existing mechanisms do not
fully address:
a) Unified distro packaging and distribution
- Distros need a single, well-understood mechanism they can
ship as an emergency update across all variants
b) Temporary lifecycle management
- Policies must be explicitly temporary and auto-remove on
kernel upgrade
c) Non-expert administrator experience
- A sysadmin should be able to see "kaf policy X is active"
and understand what it does without deep LSM knowledge
d) Zero overhead when inactive
- The patch-gap mitigation must not cost cycles during normal
operation
Existing LSMs are designed for permanent policy enforcement.
kaf is designed for temporary, emergency, CVE-specific mitigation.
6. Open questions for the kernel community
I need help with the following design decisions:
Q1: Hook placement
Should kaf use existing security_xxx() LSM hooks, or does it
need its own CONFIG_KAF stub hooks in target subsystems?
Q2: LSM vs independent framework
Should kaf.ko be implemented as a new LSM, or as an
independent framework that complements LSMs?
Q3: eBPF viability for CVE policies
Can BPF CO-RE / BTF provide sufficient cross-version stability
for distro emergency packages, or will per-version builds be
required for each kernel revision?
Q4: CONFIG_KAF=M feasibility
Can the stub hook mechanism work cleanly with CONFIG_KAF=M,
where kaf.ko may or may not be loaded? Specifically, how do
we handle the function pointer / stub interaction cleanly?
7. What I can offer
As a non-developer, I cannot write kernel code. What I can do:
- Test prototypes on Ubuntu LTS systems and provide detailed
operational feedback
- Analyze real CVEs to identify which ones could have been
mitigated by kaf and what the hook conditions would be
- Write user-facing documentation and admin tooling
- Provide feedback on profile/policy design from a sysadmin
perspective
8. Relationship to prior work
- seccomp-bpf: complementary (syscall-level vs semantic-level)
- Landlock: complementary (filesystem/network access control)
- SELinux/AppArmor/BPF LSM: complementary (permanent policy vs
emergency mitigation)
- io_uring restrictions (Jens Axboe): kaf could leverage these
hooks for emergency io_uring CVE mitigation
9. Sustainability note (not part of the technical RFC)
kaf is intended to be free and open source. Long-term
sustainability for CVE rule development and framework maintenance
may be supported through a Linux Foundation / OpenSSF fund model
and integration with distro vendors' existing support channels.
This is outside the scope of the kernel technical discussion.
Thanks for reading. I am looking forward to your feedback on
the design direction and open questions above.
Nakashima Seiichi
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.
