multikernel/sandlock

Problem Statement Sandlock provides static sandbox profiles and programmable policy_fn callbacks, but reusable authorization rules involving prior approvals, operation history, and time windows currently require application code. Dogwood provides a Rust library with Cedar-style permit/forbid rules, custom action schemas, and temporal conditions. Investigate which Sandlock policies it can express and how to integrate it without weakening confinement. Proposed Solution Explore an optional Dogwood authorization layer in the trusted supervisor and HTTP proxy. Keep Landlock and seccomp as mandatory enforcement boundaries: a Dogwood permit must never override an existing Sandlock denial. Start with process execution and HTTP requests, defining trusted event fields for executable/arguments and HTTP method/host/path. Evaluate filesystem and network policy mappings separately, preserving filesystem object semantics and avoiding TOCTOU races. Keep resource accounting, CPU throttling, COW behavio

Reconsider if the latest landlock crate could reduce our efforts of checking ABI compatibility

Granting -r /sys exposes host hardware and topology despite the explicit block on /sys/class/net; alternative paths under /sys/devices can reveal network devices too. Provide a read-only synthetic sysfs view consistent with the sandbox’s virtual CPU and network state. Hide unsupported entries and cover directory listings, symlinks, directory-relative access, and metadata without falling through to host sysfs. Account for existing GPU support with narrowly scoped device views instead of broad host PCI/NVIDIA sysfs access.

Write-side counterpart of #218. A -w /proc/self/X entry becomes a Landlock rule bound to the first pid's inode, so forked children are denied. sandlock run -r /usr -r /lib -r /lib64 -r /bin -r /etc -w /proc/self/comm -- \ sh -c "sh -c 'echo x > /proc/self/comm'; true" sh: 1: cannot create /proc/self/comm: Permission denied The first process succeeds. Affects forked workers that write oom_score_adj or task/<tid>/comm (the GPU example in docs/cli.md grants -w /proc/self/task). Proposed fix: serve policy-listed writes on behalf of the caller from procfs::handle_proc_open, opened inside /proc/<tgid> with openat2(RESOLVE_BENEATH | RESOLVE_NO_SYMLINKS). Unlike reads, keep writes policy-gated, and always refuse mem, attr/*, uid_map, gid_map, setgroups, projid_map: the injected fd carries the supervisor's credentials, and procfs checks some of these against the opener.

Problem Sandlock can synthesize file content per syscall today. python/examples/s3_handlers.py maps a /s3 namespace onto an object store using three handlers (openat, newfstatat, statx), and open("/s3/x").read() plus os.stat("/s3/x") both work. What it cannot do ergonomically is synthesize a namespace. ls /s3 is empty because nothing serves getdents64, and that caveat is documented in the example itself (line 42). Writing directory synthesis by hand is possible with the existing Handler API but hostile. A user must: Resolve which directory a getdents64 dirfd refers to by readlinking /proc/<pid>/fd/<n> from the supervisor. Pack linux_dirent64 records with correctly 8-byte-aligned d_reclen. Maintain a per-(pid, fd) cursor, because getdents64 is a stream that must advance across calls and eventually return 0. Getting this wrong makes ls loop forever. Pack struct stat by hand. The existing example does this with a hardcoded x86_64 layout (its own docstring admits this at line 50), which i