[congwang-mk]

Summary

Let a sandbox report its own kernel identity in place of the host's:

Sandbox(fs_readable=[...], uname={"release": "6.1.0", "version": "#1 SMP"})

sandlock run --uname release=6.1.0 --uname "version=#1 SMP" -- make

[uname]
release = "6.1.0"
version = "#1 SMP"

sb := &sandlock.Sandbox{Uname: map[string]string{"release": "6.1.0"}}

Fields are sysname, release, version, machine and domainname; unset fields pass the host's value through. nodename stays the sandbox name.

Use cases

Reproducible builds. Builds that record the build kernel produce different artifacts on CI runners with different kernels. Common examples are configure logs and generated headers that capture uname -a, Perl's Config.pm (osvers) and build-info stamps. reprotest, the Debian Reproducible Builds checker, treats this as a variation source: its kernel variation changes the reported uname (via setarch --uname-2.6) to catch builds that leak it. Pinning release and version removes that variation. Together with features sandlock already has, a sandbox now covers several of reprotest's variations:

reprotest variation	sandlock
kernel	uname (this PR)
domain_host	sandbox name (hostname) + uname domainname
time	time_start
fileordering	deterministic_dirs
num_cpus	num_cpus

Hiding host details. A multi-tenant or agent sandbox no longer reveals the host's exact kernel build string through uname.

This is not an exploit mitigation. Kernel behavior (which syscalls exist, the Landlock ABI, the vDSO) still reveals the real kernel, and reducing attack surface through seccomp remains the actual defense.

Design

One fact reaches a process through several channels, so each override also answers the procfs file that repeats it: /proc/sys/kernel/{ostype,osrelease,version,arch,domainname} and /proc/version. Otherwise a plain cat would contradict uname(). /proc/version is built from the fields alone, without the host's compiler banner: the banner names the build host and differs across machines, so keeping it would defeat reproducibility.

This is a policy field rather than something users build with run_with_handlers. Built-in handlers run first and cannot be overridden, and the built-in uname handler always answers (it supplies the nodename), so a user handler on uname never runs. Under chroot/COW the built-in path handler answers every open first, so a user openat handler could not serve the procfs files either. The field is implemented as built-in handlers in the same dispatch table, which also makes it available from the CLI, profiles and Go, none of which have the handler API.

Validation lives in the core builder: unknown fields, nodename, values over 64 bytes (utsname fields are char[65]) and NULs are rejected, and --no-supervisor refuses the option.

While probing this, /proc/sys/kernel/hostname turned out to leak the real host name even though uname -n and /etc/hostname show the sandbox name. The first commit fixes that on its own.

Test plan

• Rust unit tests: Uname validation, /proc/version rendering, utsname field truncation, profile round trip and rejection
• Integration: test_uname_override checks uname -r/-v/-m against /proc/sys/kernel/{osrelease,version,arch} and /proc/version; test_hostname_virtualization covers /proc/sys/kernel/hostname
• Python: TestUname (override plus unknown field rejection)
• Go: TestUnameOverride, TestParseProfileMapsFields with [uname]
• CLI by hand: profile [uname] merged with a field-wise --uname override; --no-supervisor rejection

🤖 Generated with Claude Code