Runtime Executable Deny Cannot Be Securely Implemented on Multi-Call Binary Systemen

[dwt]

Summary

The Runtime Executable Deny functionality in Fence has a fundamental design limitation on systems with multi-call
binaries (Nix, BusyBox, Alpine, etc.). The current implementation either:

• Blocks too much (entire bundle like coreutils → ls, cat, dd all blocked)
• Or can be bypassed (via --coreutils-prog= or environment variables)

---

Technical Background

Issue 1: Kernel Resolves Symlinks

# On Nix-Darwin:
/run/current-system/sw/bin/dd → /nix/store/...-coreutils/bin/coreutils

# Kernel execve() behavior:
# 1. Symlink is resolved
# 2. /proc/PID/exe points to coreutils (not dd!)
# 3. sandbox-exec / Landlock only see "coreutils"

Consequence: Blocking coreutils blocks all commands in the bundle (ls, cat, cp, mv, rm, ...).

Issue 2: $0 Is Not Trustworthy

# Theoretically one could check argv[0]:
argv[0] = "/run/current-system/sw/bin/dd"

# BUT: $0 is easily spoofed!
bash -c "exec -a /usr/bin/python3 /nix/store/...-coreutils/bin/coreutils"
# → Process appears as "python3" even though it's coreutils

Issue 3: coreutils --coreutils-prog=dd Bypass

# GNU coreutils supports explicit program selection:
coreutils --coreutils-prog=dd if=/dev/zero of=/tmp/test
# Also:
coreutils --coreutils-prog=ls -la
coreutils --coreutils-prog=cat /etc/passwd

Consequence: Even if dd is blocked, coreutils can be executed and act as dd.

Issue 4: Additional Bypasses

# BusyBox / ToyBox similarly:
busybox dd if=/dev/zero
toybox ls -la
# Shell functions / aliases:
function dd() { coreutils --coreutils-prog=dd "$@"; }
# Symlinks with different names:
ln -s /nix/store/...-coreutils/bin/coreutils /tmp/my-dd
/tmp/my-dd if=/dev/zero

Current Implementation (Fence)

Preflight Command Parsing ( command.go )

• ✅ Works on all systems
• ✅ Text-based, no paths involved
• ✅ Blocks "dd if=/dev/zero" against "dd if=" rule
• ❌ Can be bypassed with complex shell constructs

Runtime Executable Deny ( runtime_exec_deny.go )

• ✅ Blocks child processes (e.g., env python3 )
• ✅ Works well on systems with single-purpose binaries
• ❌ Multi-call systems: Either blocks everything or nothing
• ❌ Cannot distinguish dd from ls when both → coreutils

What to do?

First question is probably... how is this supposed to work? Are the two blocking layers (command parsing based and execution based) only meant as defense in depth and we only want them to be good enough to block some things?

In that case we could try to have a kind of whitelist that excludes multi call binaries like busybox, coreutils, python and a few others?

If these layers are meant to be as good as possible.... I am not sure what could be done in that case actually.

In any case, this was all triggered because /nix/store triggers an additional complexity with sandboxing that I hadn't thought about before.

I would appreciate your Input @jy-tan to understand how this is meant to work so I / we can prepare a solution.

[dwt]

I uploaded my second try at this, still need to talk to my friends at CCC about this though. Anyway, would appreciate some feedback so far. I also tried out showboat to show the difference this makes.

Fence: Smart Shared-Binary Exec-Deny

2026-03-24T18:43:40Z by Showboat 0.6.1

Background

On Nix and nix-darwin every coreutils command (ls, cat, dd, head, tail, ...) is a symlink
pointing at a single multicall binary. The same pattern appears with uutils-coreutils and busybox.

When fence resolves symlinks before building its runtime exec-deny list, blocking dd resolves to
that shared binary — which also implements ls, cat, and ~100 other commands. Without protection,
the sandbox environment breaks entirely.

This document verifies the fix: the new logic detects critical-command collisions and handles them
with three distinct behaviours, while still blocking non-critical shared binaries (e.g. python3) normally.

Versions under test

echo "system fence:" && fence --version 2>&1 | grep "Version:" && echo "local fence (this branch):" && ./fence --version 2>&1 | grep "Version:"

system fence:
  Version: 0.1.32
local fence (this branch):
  Version: dev

The shared-binary situation on this machine

dd and ls are both Nix coreutils symlinks. Verify they resolve to the same canonical binary:

echo "dd  -> $(which dd) -> $(readlink $(which dd))" && echo "ls  -> $(which ls) -> $(readlink $(which ls))" && echo && echo "canonical dd: $(realpath $(which dd))" && echo "canonical ls: $(realpath $(which ls))" && echo && echo "commands sharing that binary: $(ls $(dirname $(realpath $(which dd))) | wc -l | tr -d " ") (including the coreutils binary itself)"

dd  -> /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/dd -> coreutils
ls  -> /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/ls -> coreutils

canonical dd: /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/coreutils
canonical ls: /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/coreutils

commands sharing that binary: 107 (including the coreutils binary itself)

106 symlinks + 1 real binary, all sharing one inode. Any path fence adds to its exec-deny list that resolves to this binary will block all 106 commands at once.

The bug: system fence (v0.1.32) breaks ls when dd is denied

Config: {"command":{"deny":["dd"],"useDefaults":false}}

Without the fix, resolving dd → coreutils canonical path → that path is added to the OS exec-deny list → every one of the 106 other coreutils symlinks (ls, cat, head, tail, ...) is collaterally blocked.

fence --settings bundled-binaries/config-deny-dd.json -c "ls /tmp" 2>&1; echo "exit: $?"

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9/bin/bash: line 1: /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/ls: Operation not permitted
exit: 126

The sandbox blocks ls (exit 126) because it resolves to the same coreutils binary that dd was asked to deny. The user never asked to block ls.

Fix: local fence (dev) detects the critical collision and skips the coreutils path

Same config. The new logic detects that the coreutils canonical path also implements ls, cat, head, tail, and ~100 other critical commands — and skips adding it to the exec-deny list. The standalone macOS /bin/dd (a separate binary) is still blocked.

./fence --settings bundled-binaries/config-deny-dd.json -c "ls /tmp" 2>&1; echo "exit: $?"

MozillaUpdateLock-83AB270330835640
com.apple.launchd.GhgLYCyvQZ
com.apple.launchd.s8WZbe4DCH
fence
powerlog
textmate-501.sock
zeb_def_ipc_3503
zeb_def_ipc_7450
exit: 0

ls runs cleanly. The --debug flag logs an actionable diagnostic explaining exactly what happened and how to resolve it:

./fence --debug --settings bundled-binaries/config-deny-dd.json -c "ls /tmp" 2>&1 | grep "fence:macos"

[fence:macos] runtime exec deny skipped for /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/coreutils (requested: dd): shared binary also implements critical commands [[ basename cat cp cut date dirname echo env false head id ls mkdir mktemp mv printf pwd readlink realpath rmdir sort tail tee test touch tr true uname uniq wc whoami]. To force blocking add "allowBlockingCritical": true to your command config. To silence this warning add "dd" to "acknowledgeSharedBinary".

Opt-in: allowBlockingCritical: true forces the block anyway

Config: {"command":{"deny":["dd"],"useDefaults":false,"allowBlockingCritical":true}}

The user has explicitly accepted the risk. The coreutils path is added to the deny list — ls is blocked, no diagnostic is emitted.

./fence --settings bundled-binaries/config-deny-dd-force.json -c "ls /tmp" 2>&1; echo "exit: $?"

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9/bin/bash: line 1: /nix/store/akih5l2yxpzqyh63xvyc6zsxl7kl2x4v-coreutils-9.10/bin/ls: Operation not permitted
exit: 126

Opt-out: acknowledgeSharedBinary: ["dd"] silences the warning

Config: {"command":{"deny":["dd"],"useDefaults":false,"acknowledgeSharedBinary":["dd"]}}

The user has investigated, knows dd cannot be isolated on this system, and wants no noise about it. The coreutils path is silently skipped — ls works, and --debug logs nothing for this path.

./fence --settings bundled-binaries/config-deny-dd-ack.json -c "ls /tmp" 2>&1; echo "exit: $?"

MozillaUpdateLock-83AB270330835640
com.apple.launchd.GhgLYCyvQZ
com.apple.launchd.s8WZbe4DCH
fence
powerlog
textmate-501.sock
zeb_def_ipc_3503
zeb_def_ipc_7450
exit: 0

./fence --debug --settings bundled-binaries/config-deny-dd-ack.json -c "ls /tmp" 2>&1 | grep "fence:macos" || echo "(no diagnostic logged)"

(no diagnostic logged)

Non-critical shared binary: python3 is still blocked

Config: {"command":{"deny":["python3"],"useDefaults":false}}

python3, python3.13, and python3-config share a single binary on this machine — but none of those names are on the critical-commands list. There is no collateral damage to worry about, so the runtime exec-deny proceeds normally. ls is completely unaffected.

./fence --settings bundled-binaries/config-deny-python3.json -c "ls /tmp" 2>&1; echo "exit: $?"

MozillaUpdateLock-83AB270330835640
com.apple.launchd.GhgLYCyvQZ
com.apple.launchd.s8WZbe4DCH
fence
powerlog
textmate-501.sock
zeb_def_ipc_3503
zeb_def_ipc_7450
exit: 0

./fence --settings bundled-binaries/config-deny-python3.json -c "bundled-binaries/run-python3.sh" 2>&1; echo "exit: $?"

bundled-binaries/run-python3.sh: line 2: /Users/dwt/Library/Caches/uv/archive-v0/TvtNho9_JQhr2BYzP0HOg/bin/python3: Operation not permitted
exit: 126

The runtime exec-deny fires at the OS level: the sandbox blocks the python3 binary path directly (the preflight never sees the command). ls is completely unaffected because none of python3's shared names appear on the critical-commands list.

---

Some thought: I am thinking that maybe configuring blocking that blocks critical binaries might be something we want to always show, not only when --debug is given. What do you think?