CLI doesn't allow opt-out of syscall filter

[bittervec]

Background

Today I couldn't get sandlocked bun to work, where either bun repl or bun test silently exits with code 1. I figure it may have something to do the syscall filtering enforced by sandblock after ruling out possible interfering of filesystem rules.

Problem

The CLI help page reports two relevant options on this, --extra-deny-syscall and --extra-allow-syscall. Despite similar naming, notice that --extra-allow-syscall only accepts syscall group instead of specific syscalls, which is fairly confusing.

      --extra-deny-syscall <NAME>
          Extra syscall names to deny (in addition to Sandlock's default blocklist)
      --extra-allow-syscall <NAME>
          Extra syscall group names to allow (e.g. sysv_ipc)

After consulting the source code, there seems to be only two groups defined so far, default and sysv_ipc. And sysv_ipc is the only one we are able to disable with the option.

Questions

1. I notice that the default syscall blocklist is quite comprehensive. Must the default blocklist be enforced to protect the security model sandlock is based off? For example, would sandbox escape become possible if I check some syscalls off from the default blocklist?
2. If the opt-out is not an option due to the first point, does it limit the use cases of sandlock even for some common development tasks (say bun in my example)?

[dzerik]

On the io_uring part specifically:

io_uring_setup/io_uring_enter/io_uring_register are on the default blocklist for a real reason — io_uring's submission-queue does I/O asynchronously and bypasses per-syscall seccomp, so a sandboxed task could use it to perform file/network I/O that never passes through sandlock's Landlock/seccomp mediation. So this one can't simply be allowed back in without punching a hole in the model (re: your Q1 — yes, allowing io_uring would let I/O escape mediation).

That said, it's currently denied with EPERM. A runtime that probes io_uring and treats EPERM as a hard error will fail, whereas ENOSYS ("not implemented") makes most runtimes fall back to epoll/blocking I/O. Reporting ENOSYS for io_uring while keeping it fully denied looks like a low-risk UX fix. I prototyped it and confirmed a real io_uring_setup(2) inside the cage then returns ENOSYS instead of EPERM.

However — I could not reproduce the bun repl / bun test silent exit 1. What I tried:

• Environment: Bun 1.3.6, sandlock from current main, Linux with Landlock + seccomp active.
• Invocation: sandlock run -r /usr -r /lib -r /lib64 -r /etc -r /proc -r /dev -r ~/.bun -r /tmp -w /tmp -- bun test x.test.js (also bun -e "console.log(40+2)").
• Result: bun test and bun -e both run to success (exit 0) — with io_uring denied as EPERM and as ENOSYS. In this setup Bun degrades gracefully on the io_uring denial either way, so io_uring being blocked did not produce the exit 1.
• The sandbox was genuinely engaged: reading an ungranted path (~/.ssh/id_rsa) returned EACCES and io_uring was denied — Bun just kept working within its grants.

So your exit 1 is likely something else — a different Bun/kernel version, or a different blocklisted syscall. To pin it down, strace Bun without sandlock (you can't strace inside the cage — ptrace is itself blocklisted, so strace's own ptrace gets EPERM), then cross-reference:

strace -f -c bun test    # run normally, NOT under sandlock

Check which of the syscalls Bun issues appear in DEFAULT_BLOCKLIST_SYSCALLS (mount, unshare, setns, userfaultfd, keyctl, perf_event_open, personality, io_uring_*, …). A syscall Bun needs that the blocklist denies with EPERM is the likely cause of the exit 1 — that name is what we need. Also handy: bun --revision and uname -a, plus the exact sandlock invocation (all --fs-* flags) you used.

If it does turn out to be io_uring, the ENOSYS change above should resolve it.