RFC: Generate minimal profile by observing a workload (`sandlock learn`)

[congwang-mk]

Goal

Add a sandlock learn -- <cmd> mode that runs a workload under instrumentation and emits a minimal sandlock profile (TOML) covering exactly the filesystem reads/writes, network egress, and syscalls the workload actually used. Subsequent sandlock run -p <profile> invocations confine the workload to just that observed surface.

Motivation

Writing a tight policy from scratch is the single largest UX gap with the flag-based interface. To run a Python script under sandlock today, the user has to know which directories cpython, site-packages, ssl certs, locale archives, and tempdirs live in. Most users give up and write -r /usr -r /lib -r /lib64 -r /etc -w /tmp, which is wide enough to be close to no policy. The result is a sandbox in name only.

The XOA model assumes per-call confinement is tight enough to matter. If the per-call profile is permissive by default, the threat model degrades to "container without a container," which is worse than what we promise.

The way out is observation. Run the workload once, record what it actually touches, emit a profile. The user starts from "definitely works, definitely minimal" rather than "guess and iterate."

Proposed design

Command surface

sandlock learn -o profile.toml -- python3 build.py
sandlock learn --merge profile.toml -- python3 build.py   # union into existing
sandlock run -p profile.toml -- python3 build.py

What is recorded

Domain	Recording mechanism
Filesystem reads	Permissive Landlock + seccomp-notify on openat/open
Filesystem writes	Same; classified by open flags (O_WRONLY / O_RDWR / O_CREAT)
Network egress (TCP / UDP / ICMP)	seccomp-notify on connect / sendto / sendmsg
HTTP method + host + path	Existing transparent proxy with --http-ca, in logging-only mode
Syscalls	seccomp filter counts unique syscalls invoked
Resource peaks	/proc/<pid> sampling: max RSS, max threads, max FDs

Output format

Reuse the existing TOML profile serializer in crates/sandlock-core/src/profile.rs. Fields populated:

• fs.readable / fs.writable: minimal path prefixes covering observed accesses, collapsed to directory granularity (see below).
• net.allow: observed host:port pairs, with scheme prefix when non-TCP.
• http.allow: observed method+host+path rules. Optional, gated by --learn-http.
• seccomp.allow: minimal syscall set, gated by --learn-syscalls; otherwise omit and rely on the default profile.
• limits.max_memory / limits.max_processes: observed peak times a safety factor (default 1.5x, configurable).

The output carries a header comment with the input command, host kernel, and timestamp, so reproduction is unambiguous.

Path collapsing

Recording one entry per file is unworkable: a Python import touches thousands. The collapser groups by directory using a tunable heuristic:

• If the workload touched at least N files (default 4) under a directory, allowlist the directory.
• If fewer, allowlist individual files.
• --collapse N and --collapse-prefix /usr/lib/python3 force aggregation.

Merging and iteration

--merge profile.toml performs a union: existing rules retained, new rules added; resource caps take the max of old vs observed. Iterative refinement is the expected workflow: run with one input, run with another, merge.

When a later sandlock run -p hits a denial, the seccomp/Landlock log line should suggest sandlock learn --merge profile.toml -- ... to extend the profile.

Open questions

1. Permissive-Landlock + notify vs notify-only. Landlock has no native audit mode. Either accept denials and observe them, or run with rules fully permissive and observe via seccomp-notify on file syscalls. Latter is heavier per-syscall but complete. Decide during prototype.
2. eBPF as alternative recorder. A bcc/bpftrace tracer would be much faster than seccomp-notify but adds a build dependency. Out of scope for v1; revisit if seccomp-notify overhead is prohibitive on realistic workloads.
3. Per-invocation log vs aggregate. Probably emit both: the aggregated profile is the artifact, a side-channel --debug-log records every observation for diagnosing the collapser.
4. Multi-process workloads. Forks inherit the seccomp filter; the supervisor already aggregates across children for runtime sandboxes. Same machinery applies; verify in prototype.

Out of scope for v1

• Replay / fuzzing across input variants to broaden the trace.
• ML-guided rule generalization.
• Auto-tightening: take an existing profile, identify rules that no recorded run actually exercised, suggest removal. Useful follow-on once learn lands.

[dzerik]

Thanks for opening this — the diagnosis (default-broad policies because tight ones are unworkable to write) matches what we see downstream, and the observation-based approach is the right direction. To be clear upfront: this is a high-value feature on the user-facing axis — solving the "I have no idea what my workload needs" gap is a real unlock for teams that today ship default-wide policies. Our concern below is specifically about how the affordance behaves in less-experienced hands, not about whether the feature should ship.

One concern on the path-collapsing mechanism, worth raising before implementation: it risks reproducing the exact failure mode the motivation is trying to fix.

The N=4 default + directory collapse over-grants on sensitive paths

The rule —

"If the workload touched at least N files (default 4) under a directory, allowlist the directory."

— is "minimum so the workload still runs," not "minimum permission." The two diverge sharply at any directory where unobserved siblings carry sensitive content. Concrete cases that fire on routine workloads:

/etc: a Python script reading /etc/hostname, /etc/resolv.conf, /etc/passwd (group lookup), /etc/services during normal setup hits N=4 → profile gets fs.readable: /etc. That now allows /etc/shadow, /etc/sudoers, /etc/ssh/*, /etc/krb5.keytab — none touched during learn. Any later production-time vector that reaches those paths (path traversal in a tool, prompt injection in an LLM agent, CVE in a dependency) is now policy-allowed.

/proc: a Python interpreter routinely reads /proc/self/maps, /proc/cpuinfo, /proc/version, /proc/meminfo at startup — N=4 by default. Profile gets fs.readable: /proc. That grants /proc/<pid>/maps and /proc/<pid>/mem of other processes, /proc/<pid>/cmdline (which often inlines secrets like OPENAI_API_KEY=sk-...), /proc/<pid>/environ, /proc/kallsyms. None observed during learn.

The same pattern fires on $HOME (touch 4 cache files → ~/.ssh/, ~/.aws/, ~/.kube/ accessible) and on /var/log write-side (write 4 log files → write access to host audit logs).

This is the exact "-r /etc is wide enough to be no policy" failure the motivation calls out — sandlock learn risks shipping it under a friendlier API.

Tool affordance compounds the risk

The framing first, because this pattern is worth naming explicitly — we've watched "convenient policy / profile generators that produce slightly-too-wide rules" turn into false-sense-of-security incidents in practice often enough that the failure mode deserves a slot in the design conversation, not just an implementation-time fix. The affordance is what creates the trap: easy to generate, hard to audit, output looks minimal.

A connected concern, tied to the same mechanism: sandlock learn lowers the skill bar required to produce a profile, while leaving the skill bar required to audit what was produced at least as high as writing the policy from first principles. A senior engineer typing -r /etc knows their policy is wide and ships it deliberately. A junior engineer running sandlock learn, seeing fs.readable: /etc in a well-formatted TOML output with a kernel-version header, most likely concludes "the tool figured out what my script needs" and ships it as the tight profile the motivation promises. Same /etc grant — first knows it, second believes the opposite.

The asymmetry — easy to generate, hard to audit, output that looks authoritative — is the dangerous shape. The operators who most need the "definitely works, definitely minimal" safety net are precisely those least likely to catch when the collapser silently crossed from safe to overly-permissive. The tool grants more confidence than the mechanism deserves.

What feels missing from the design

Not prescriptive — flagging directions:

• Sensitive-prefix deny-list inside the collapser. A small list the collapser refuses to aggregate regardless of N: /etc, /proc, /sys, /dev, /root, ~/.ssh, ~/.aws, ~/.kube, ~/.gnupg. Touched files there stay as individual entries.

• Diff between observed and granted on output. Before emitting fs.readable: /etc, print what becomes accessible that the workload didn't touch — so the operator chooses consciously rather than reading a clean TOML.

• --collapse-prefix validation. --collapse-prefix /etc should require explicit --force-sensitive-collapse or interactive confirmation, not silently produce a recursive grant.

• Threat model around learn-time execution. Open question Support UDP port remapping #1 already notes the recording session runs with permissive Landlock — worth either documenting "learn runs trusted code only" prominently, or routing learn-time reads through the same default-deny lens the production profile will get. (A maliciously-crafted workload at learn time can deliberately touch 4 files in sensitive directories to widen the resulting profile for a subsequent production-time exploit — supply-chain attack on profile generation.)

Happy to dig into any of this if it's useful.