fix: allow sendmsg(2) and recvmsg(2) syscalls in our Linux sandbox (#7779)

This changes our default Landlock policy to allow `sendmsg(2)` and
`recvmsg(2)` syscalls. We believe these were originally denied out of an
abundance of caution, but given that `send(2)` nor `recv(2)` are allowed
today [which provide comparable capability to the `*msg` equivalents],
we do not believe allowing them grants any privileges beyond what we
already allow.

Rather than using the syscall as the security boundary, preventing
access to the potentially hazardous file descriptor in the first place
seems like the right layer of defense.

In particular, this makes it possible for `shell-tool-mcp` to run on
Linux when using a read-only sandbox for the Bash process, as
demonstrated by `accept_elicitation_for_prompt_rule()` now succeeding in
CI.
This commit is contained in:
Michael Bolin
2025-12-09 09:24:01 -08:00
committed by GitHub
parent 164265bed1
commit a7e3e37da8
2 changed files with 1 additions and 7 deletions

View File

@@ -1,8 +1,4 @@
// TODO(mbolin): Get this test working on Linux. Currently, it fails with:
//
// > Error: Mcp error: -32603: sandbox error: sandbox denied exec error,
// > exit code: 1, stdout: , stderr: Error: failed to send handshake datagram
#[cfg(all(target_os = "macos", target_arch = "aarch64"))]
#[cfg(any(all(target_os = "macos", target_arch = "aarch64"), target_os = "linux"))]
mod accept_elicitation;
#[cfg(any(all(target_os = "macos", target_arch = "aarch64"), target_os = "linux"))]
mod list_tools;