1410191 - Some sandbox syscall interceptions turn all errors into EPERM

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement, P2)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Some of the trap functions used in the seccomp-bpf policy use syscall() to delegate to a syscall which isn't blocked.  However, the trap registry expects return values to work like the actual syscall ABI — errors returned as negative numbers — whereas syscall() works like the other traditional C wrappers and returns -1 with the error in errno.

So, when we do `return syscall(...)` in that context, any error means returning -1, which is -EPERM instead of whatever the actual error is.

There are several ways to fix this.  The simplest might be to use sandbox::Syscall::Call from the Chromium source, which returns the real return value.  (Its actual purpose is to make syscalls with a known rIP, so they can be allowed as part of a non-enforcing warn-only policy, but that doesn't make a difference for our sandboxing.)

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1410191 - Correctly handle errors when using syscalls in sandbox trap handlers.

Review commit: https://reviewboard.mozilla.org/r/193186/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/193186/

Comment 2

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8922166 [details]
Bug 1410191 - Correctly handle errors when using syscalls in sandbox trap handlers.

https://reviewboard.mozilla.org/r/193186/#review198690

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/671e6d994ecb
Correctly handle errors when using syscalls in sandbox trap handlers. r=gcp

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/671e6d994ecb