[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5298260b9354b674f4954868755682398f05e83.camel@kjb.biglobe.ne.jp>
Date: Wed, 11 Nov 2026 05:56:02 +0900
From: Nakashima Seiichi <s-nakashima@....biglobe.ne.jp>
To: kernel-hardening@...ts.openwall.com,
linux-security-module@...ts.linux.dev
Cc: keescook@...omium.org, paul@...l-moore.com, mic@...ikod.net
Subject: [RFC v3] kaf: CVE Emergency Mitigation Policy Standard Specification
Hi all,
This is v3 of the Kernel API Firewall (kaf) proposal.
Unlike v1 and v2+, this revision is NOT a kernel patch proposal.
After candid assessment of implementation constraints, I have changed
the design direction fundamentally.
=== What changed ===
v1/v2+ proposed a 3-layer kernel architecture:
CONFIG_KAF stub hooks -> kaf.ko LKM -> eBPF policy modules
This required either (a) me writing all kernel code, or (b) a kernel
developer volunteering to implement it. Realistically, neither is
likely to happen on a timescale relevant to CVE emergency mitigation.
Kernel patch review and consensus can take months to years, which
directly contradicts the "emergency" nature of the problem.
Investigation revealed that mechanisms capable of blocking vulnerable
code paths at the kernel level already exist:
- Tetragon (eBPF-based runtime enforcement)
- BPF LSM (Linux 5.7+, kernel standard)
- seccomp-bpf
- Landlock
What does NOT exist is a standard for packaging, distributing, and
managing CVE-specific emergency mitigation policies on top of these
mechanisms. That is what kaf v3 defines.
=== What kaf v3 IS ===
kaf v3 is a standard specification for:
- CVE-specific emergency mitigation policy format (YAML)
- Policy packaging conventions for distributions
- Policy lifecycle management (pending -> active -> disabled)
- Cross-backend audit log format (JSON)
- Abstract backend interface (Tetragon / BPF LSM / seccomp-bpf)
kaf v3 is NOT:
- A new kernel feature or LSM
- A replacement for seccomp, SELinux, AppArmor, or BPF LSM
- A general syscall filtering mechanism
=== Why existing tools alone are insufficient ===
Tetragon is powerful for runtime enforcement, but it does not define:
- CVE-specific policy packaging (e.g., apt install kaf-policy-cve-
XXXX)
- Automatic policy removal after kernel patch application
- A standard audit log format across backends
- Embargo-period policy distribution workflow
Distributions need a single, well-understood mechanism they can ship
as an emergency update. kaf provides the standard that makes this
possible without waiting for kernel development.
=== Specification ===
The full specification (HTML) is attached to this email.
It includes:
- Policy YAML schema with backend abstraction
- Package naming and directory conventions
- Lifecycle state machine (pending/active/audit-only/disabled)
- JSON audit log specification
- kafctl CLI specification
- Three concrete implementation examples (Tetragon, BPF LSM, seccomp-
bpf)
- Pre-disclosure defense workflow
=== Questions for the community ===
Q1: Is the backend abstraction design sound?
Can one policy definition reasonably target multiple backends
(Tetragon, BPF LSM, seccomp-bpf) with backend-specific configs?
Q2: Are the packaging conventions practical for distributions?
Debian/Ubuntu/Fedora packagers: would you ship kaf-policy-*
packages?
Q3: Is the audit log format sufficient for cross-backend aggregation?
SIEM/security monitoring folks: what fields are missing?
Q4: Does the lifecycle state machine (auto-disable on kernel patch)
work with your distro's update mechanisms?
Q5: Is there interest in forming a working group around this standard?
I can provide: CVE analysis, operational design, documentation,
and testing on Ubuntu LTS. I need help with: reference
implementation (kaf-cli, kafd), distro packaging, and backend
integration.
=== What I can offer ===
- Analyze real CVEs to identify which ones could have been mitigated
by kaf and what the policy conditions would be
- Test prototypes on Ubuntu LTS and provide operational feedback
- Write user-facing documentation and admin tooling specs
- Provide feedback on policy design from a sysadmin perspective
I am not a kernel developer. I seek collaboration from those who are,
as well as distribution security teams, eBPF practitioners, and
operations engineers.
=== 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)
- Tetragon: kaf uses Tetragon as one of its backend implementations
Thank you for reading. I look forward to your feedback on whether
this standardization direction is useful.
=== Acknowledgments ===
This v3 revision would not have been possible without the assistance
of Namazu, an AI assistant developed by Sakana AI. The investigation
of existing mechanisms (Tetragon, BPF LSM, seccomp-bpf), the
realization that kernel implementation was impractical given current
constraints, the design of the backend abstraction, and the structure
of this specification were all developed through collaborative
discussion with Namazu.
Nakashima Seiichi
Sakana AI's Namazu
View attachment "kaf_standard_specification_en.html" of type "text/html" (35599 bytes)
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.
