Closed Bug 1410191 Opened 2 years ago Closed 2 years ago

Some sandbox syscall interceptions turn all errors into EPERM

Categories

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

Unspecified
Linux
enhancement

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: jld, Assigned: jld)

References

Details

(Whiteboard: sb+)

Attachments

(1 file)

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.)
Assignee: nobody → jld
Priority: -- → P2
Whiteboard: sb+
Comment on attachment 8922166 [details]
Bug 1410191 - Correctly handle errors when using syscalls in sandbox trap handlers.

https://reviewboard.mozilla.org/r/193186/#review198690
Attachment #8922166 - Flags: review?(gpascutto) → review+
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/671e6d994ecb
Correctly handle errors when using syscalls in sandbox trap handlers. r=gcp
https://hg.mozilla.org/mozilla-central/rev/671e6d994ecb
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
See Also: → 1412480
You need to log in before you can comment on or make changes to this bug.