Sandbox escape by racing seccomp notifications?

[Changaco]

Sandlock is partly based on seccomp notifications and appears to be implying that they can be safely used for something the seccomp_unotify(2) man page warns against, i.e. to make a security decision to allow a syscall to proceed, which is unsafe due to TOCTOU race conditions. I think this limitation needs to be mentioned at least in the README sections where policy_fn is documented. Additionally, it might be a good idea for every function which returns NotifAction::Continue to explain why it's safe to do so.

[congwang-mk]

Thanks for raising this. Both of your asks landed:

PR #28 — audited every NotifAction::Continue site, added module-level safety contracts explaining why each is safe. The audit also surfaced and fixed one bug: sendmsg_on_behalf was falling through to Continue on msghdr-read failure (a racing thread could have skipped the IP allowlist); it now returns EFAULT.

PR #29 — redesigned the policy_fn event surface around "every held syscall gets the strongest safety its kernel structure allows":

• Path strings (event.path, path_contains) dropped from events. Path-based access control belongs in static Landlock rules (fs_read / fs_write / fs_deny); ctx.deny_path() stays for runtime additions.
• event.argv for execve kept and made TOCTOU-safe. Since execve can't be done on-behalf (the kernel must run it in the calling thread), the supervisor now PTRACE_SEIZE + PTRACE_INTERRUPTs sibling threads of the calling tid before sending Continue. The pause is effectively zero-cost — execve's de_thread kills siblings anyway. If the freeze fails (YAMA, etc.), the execve is denied closed.

The README's Dynamic Policy section now has an explicit TOCTOU note. Closing as resolved.

[Changaco]

I'm not sure freezing the sibling threads is sufficient to prevent all races. Couldn't a different process in the same sandbox modify the arguments if they're stored in shared memory?