Writable files in allowWrite fail for programs using atomic writes (e.g. ~/.claude.json)

[tito]

Description

Files listed in allowWrite (such as ~/.claude.json) appear as read-only inside the sandbox when the sandboxed program uses atomic file writes. This affects Claude Code login, which writes to ~/.claude.json, and likely other tools that follow the same pattern (ssh writing known_hosts, git config, etc.).

Steps to Reproduce

1. Add ~/.claude.json to allowWrite in a greywall profile
2. Run greywall -- claude login (or any command that triggers a write to ~/.claude.json)
3. Claude reports "read only file system" for ~/.claude.json

Root Cause

Many programs use atomic file writes: they write to a temporary file (e.g. ~/.claude.json.tmp.PID.TIMESTAMP), then rename() the temp file over the target. This pattern breaks in greywall's Linux sandbox at two layers:

1. Bwrap: Cross-filesystem rename (EXDEV)

In DefaultDenyRead mode, the home directory is a tmpfs (--dir /home/user). Writable files get individual bind mounts from the host (--bind ~/.claude.json ~/.claude.json). When the program creates a temp file, it lands on the tmpfs. The target file is on the host filesystem (bind-mounted). rename() across different filesystems fails with EXDEV.

2. Landlock: No MAKE_REG on parent directory

When Landlock adds write rules for individual files (not directories), it strips directory-only rights like MAKE_REG, REMOVE_FILE, and REFER from the access mask. The file only gets WRITE_FILE + TRUNCATE (0x4002). Creating temp files in the parent directory is blocked by Landlock because the parent directory doesn't have MAKE_REG permission.

Impact

Any program that uses atomic writes to individually-listed writable files outside of CWD will fail. This includes:

• Claude Code (~/.claude.json)
• SSH (~/.ssh/known_hosts)
• Various CLI tools that write config files atomically

Environment

• Linux with Landlock (kernel 5.13+)
• DefaultDenyRead mode enabled
• Writable files listed individually in allowWrite (not inside an already-writable directory like CWD)

[tito]

Linux security limitations compared to macOS

I did some research into why this happens and what our options are. The short version is that the Linux security primitives available to unprivileged processes simply cannot express "allow writing to this specific file pattern inside a directory, but deny everything else."

On macOS, Seatbelt profiles support both allow and deny rules with regex patterns, and deny takes precedence over allow. So you can write something like:

(allow file-write* (regex #"^/Users/tito/\.claude\.json"))
(allow file-write* (regex #"^/Users/tito/\.claude\.json\."))
(deny file-write* (subpath "/Users/tito"))

This gives you precise per-file control inside a writable directory with zero security tradeoff. macOS is also affected by this bug (the temp file patterns need to be in the write allow list), but the fix there is straightforward and does not weaken anything.

On Linux, we have Landlock and seccomp, and neither can do this:

Feature	macOS Seatbelt	Linux Landlock
Allow rules	Yes	Yes
Deny rules	Yes	No (additive only)
Path patterns (regex/glob)	Yes	No (exact paths only)
Deny overrides allow	Yes	N/A
Per-file granularity in writable dir	Yes	No

Landlock is purely additive and hierarchical. Once you grant MAKE_REG on a directory, any file can be created there. There is no mechanism to say "only allow creating files matching ~/.claude.json.*". Seccomp works at the syscall level and has no awareness of file paths at all.

The quick fix and what it opens up

The most direct fix on Linux would be to bind-mount the parent directory (home) as writable in bwrap, then re-overlay all the read-only mounts on top to protect existing files. We would also need to grant Landlock write access to the parent directory for the atomic write to succeed.

This does fix the atomic write problem, but it opens a real security gap. Since Landlock has no deny mechanism, granting write access to the home directory means every file underneath becomes Landlock-writable. The bwrap re-overlay protects existing files (they get ro-bind on top), but new file creation in the home directory is completely unrestricted. A sandboxed process could create arbitrary new files on the host filesystem, which is a meaningful departure from the DefaultDenyRead model we have today.

[tito]

Other Linux security mechanisms that could work

There are Linux security mechanisms that support path-based deny rules, but they all come with significant constraints for our use case.

AppArmor can do exactly what we need. It supports path-based allow/deny with glob patterns, and deny overrides allow. A profile like allow /home/tito/.claude.json* rw combined with deny /home/tito/** w would be perfect. However, AppArmor requires root or CAP_MAC_ADMIN to load profiles, and it is only available on Ubuntu, Debian, and SUSE. It is not present on Arch, Fedora, or RHEL. That makes it a non-starter as a general solution since greywall needs to work unprivileged and across distros.

SELinux could also handle this through its label-based access control, but it has similar constraints. It requires root for policy management, and it is only available on Fedora, RHEL, and CentOS. It is also mutually exclusive with AppArmor; you run one or the other.

eBPF LSM is the most interesting option. It allows loading custom security programs into kernel LSM hooks that can inspect file paths and return allow/deny decisions. It works on any distro with a recent kernel compiled with CONFIG_BPF_LSM=y and bpf in the active LSM list. The catch is that it requires CAP_BPF or root to load the BPF programs. It cannot run unprivileged.

Mechanism	Can deny within writable dir	Unprivileged	Distro availability
Landlock	No	Yes	Everywhere (kernel 5.13+)
AppArmor	Yes	No (root)	Ubuntu, Debian, SUSE only
SELinux	Yes	No (root)	Fedora, RHEL, CentOS only
eBPF LSM	Yes	No (CAP_BPF)	Any distro with BPF LSM kernel config

So any solution that actually solves the deny-within-writable-directory problem requires elevated privileges. The question is whether we want to support an optional enhanced mode when CAP_BPF is available.

[tito]

eBPF LSM research: what exists today and what it would take

I spent some time looking into what already exists in the eBPF LSM space and what building this for greywall would look like.

What exists today

KubeArmor is the most production-ready implementation. It is a runtime security engine that uses BPF LSM to enforce path-based file allow/deny policies. It works by translating user-specified policy rules into eBPF bytecode, loading them into kernel LSM hooks (security_file_open, security_inode_create, security_inode_rename), and making allow/deny decisions on every file operation. Internally it hashes file paths into BPF maps and does lookups at each hook point.

KubeArmor was originally built for Kubernetes but can run standalone in systemd mode on bare-metal or VMs. The problem is that it runs as a persistent root daemon. It is a system service that manages BPF program lifecycle, policy updates, and event logging. That model does not fit greywall at all; we need per-command ephemeral sandboxing without a background service.

BPFBox and BPFContain are academic prototypes that take a similar approach. BPFContain is written in Rust using libbpf-rs and translates pathnames to inode+device pairs at policy load time (which is clever since it defeats TOCTOU attacks). Both are research-grade and not production-ready, and both require root.

Tracee (by Aqua Security) is another eBPF security tool that has robust path resolution code for walking the kernel dentry chain inside eBPF programs. Their get_path_str implementation is a good reference for the hardest part of this work.

What building it for greywall would involve

The main components would be:

1. A BPF LSM C program (~400-500 lines) attached to file_open, inode_create, inode_rename, and inode_unlink hooks. Each hook checks if the calling process is our sandboxed process, resolves the file path, and looks it up in allow/deny BPF maps.

2. Path resolution from dentry (~200-300 lines of C). This is the hardest part. eBPF has a 512-byte stack limit while paths can be 4096 bytes, so you have to walk the dentry chain manually and store results in per-CPU BPF maps. The eBPF verifier also restricts loop iterations, which makes this tricky to get right.

3. Path matching without regex. The eBPF verifier does not allow regex or complex string operations. The practical approaches are hashing full paths for exact map lookups (what KubeArmor does), prefix matching with a trie in BPF maps, or pre-expanding globs into concrete paths at load time (which greywall already does for Landlock).

4. A Go loader (~300-400 lines) using the cilium/ebpf library to load the compiled BPF bytecode, populate BPF maps with the allow/deny rules from greywall config, attach to LSM hooks, and clean up on sandbox exit.

5. Process scoping to ensure the BPF enforcement only applies to our sandboxed process and its children, not the whole system. Either PID-based (tracking forks in a BPF map) or cgroup-based (cleaner isolation but requires cgroup management).

Constraints and concerns

• Requires CAP_BPF at minimum, so this would be an optional enhancement layer on top of the existing Landlock + bwrap stack, not a replacement
• Adds cilium/ebpf as a dependency (currently greywall has only 4 direct deps)
• BPF program must be loaded before the sandboxed process starts, so sequencing during sandbox setup matters
• Kernel portability: BPF CO-RE (Compile Once Run Everywhere) helps but kernel struct layouts can still vary
• Not all users will have CAP_BPF available, so the existing Landlock path must continue to work as the baseline

The result would be the tightest file access control possible on Linux without a root daemon, filling exactly the gap that Landlock cannot: per-file deny rules within a writable parent directory.