Track 1 / AI usage at OS & kernel level
Kernel Surface Ledger
Kernel attack surface is treated as an accountability problem, not a checklist. ksl answers three questions no existing tool answers together: who holds the dangerous surface open, what is reachable but used by nothing, and which reversible changes kill the most reachable CVE mass per unit of breakage risk.
01 / the pitch
Sixty seconds
What a reviewer should take away before opening anything else.
problem
Every hardening tool produces a flat list of things that are true about a kernel. None of them says which of those things this host is actually paying for, so operators either apply nothing or apply a blanket profile and break production.
insight
Surface only matters when it is reachable, and it is only defensible when something uses it. Trace what workloads touch, attribute the rest, and a large fraction of a typical host's reachable surface turns out to be held by nobody.
result
A ledger naming the owner of every unit of reachable surface, an orphan set removable at zero functional cost, and a ranked plan where each step ships its artifact, its detection command and its revert.
02 / track fit
Against the problem statement
| asked for | how ksl does it |
|---|---|
| Analyze kernel configurations | Parses /boot/config-* and the runtime sysctl set, gating each option by whether it is actually reachable on this host rather than comparing against a static recommended list. |
| Analyze loaded kernel modules | Enumerates available modules via modules.dep, not just loaded ones, and treats unprivileged autoload triggers as reachability — the case config linters miss. |
| Analyze system calls | Observes real syscall usage per workload through the trace backend for a fixed window, which is what makes attribution and the orphan class possible at all. |
| Analyze exposed kernel interfaces | Device nodes, namespaces, capabilities, LSM state and sysctls, each carrying its gate reason and CVE clusters. |
| Identify potential security weaknesses | Weighted reachable surface with CVE cluster mapping, split into three tiers so a reviewer can separate exposure from presence. |
| AI capability, integrated | The model narrates attribution causally, predicts host-specific breakage, and synthesises each hardening artifact and its revert. Scoring stays deterministic — the ledger is reproducible with --no-explain. |
03 / where the AI is
Load-bearing, and bounded
The most common failure of an AI security tool is a model that quietly invents the numbers.
The model does
- Explain causally why a workload holds the surface attributed to it.
- Predict what a hardening step would break on this specific host.
- Synthesise the artifact for each step — blacklist, sysctl drop-in, seccomp profile.
- Write the matching revert, and answer free-form questions grounded in the report.
The model does not
- Score, weight or rank anything.
- Decide reachability, ownership or orphan status.
- Choose the plan order — that is a weighted set cover.
- Produce any number that appears on the dashboard.
Determinism claim, checkable: running with --no-explain yields byte-identical scored output. Read the full stage boundary on the pipeline page.
04 / limits
Stated up front
ksl is userspace: it reads the kernel's interfaces from outside rather than running in kernel context. "Used" means used during the observation window, so a nightly job can look orphaned at noon. Without a working trace backend the attribution half degrades to everything-unused, and the report says so instead of hiding it.
The complete list, with the failure mode of each gate, is on the method page, and the comparison against existing tools is on prior art.