fix: allow sendmsg(2) and recvmsg(2) syscalls in our Linux sandbox #7779
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes our default Landlock policy to allow
sendmsg(2)andrecvmsg(2)syscalls. We believe these were originally denied out of an abundance of caution, but given thatsend(2)norrecv(2)are allowed today [which provide comparable capability to the*msgequivalents], 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-mcpto run on Linux when using a read-only sandbox for the Bash process, as demonstrated byaccept_elicitation_for_prompt_rule()now succeeding in CI.