Closed Bug 1889045 Opened 8 months ago Closed 7 months ago

Update security/sandbox/* components to handle new syscalls

Categories

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

Firefox 124
defect

Tracking

()

RESOLVED FIXED
127 Branch
Tracking Status
firefox127 --- fixed

People

(Reporter: juippis, Assigned: jld, NeedInfo)

References

Details

Attachments

(2 files)

Steps to reproduce:

Start Firefox-124.0.1 with new glibc and libevent.

Actual results:

Browsers is unusable with messages:

[warn] epoll_wait: Function not implemented
[899883] Sandbox: seccomp sandbox violation: pid 899883, tid 899888, syscall 441, args 12 140694333724288 32 0 0 8.

Expected results:

Browser is usable.

Here's a downstream bug with all information:
https://bugs.gentoo.org/928137

Here's also a patch that handles __NR_epoll_pwait2 specifically:
https://bugs.gentoo.org/928137#c10
https://928137.bugs.gentoo.org/attachment.cgi?id=889218

but most likely other new syscalls from Chromium should be synced to Firefox while at it:
https://github.com/chromium/chromium/commit/5e08782516d24de536e75d6bf4ff2bc87be55124

I'm not exactly sure can the whole Chromium's sandbox component be synced all-at-once?

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Security
Product: Firefox → Core
Component: DOM: Security → Security: Process Sandboxing

In the past we've updated the syscall number headers independently from the rest of security/sandbox/chromium as needed; see e.g. bug 1713776.

See Also: → 1713776
Severity: -- → S3
Priority: -- → P2

Gentoo's patch will need some changes: we'll want to update the full list of syscalls, not just add this one syscall to the middle of the list, out of order, the way they did.

In our version of the headers there are example commands that download the relevant source file and generate the defines, for: x86-64 x64-32 arm-64 arm-32 (note that they all specify kernel 5.8 as written, so that should be changed). Copying the new definitions from Chromium should also work, because we don't need anything newer than their latest update for this.

We've also been including changes like this in our diffs against upstream Chromium, although I'm not sure if we need to do that in this case, given that upstream Chromium also has these updates.

Gentoo's patch is broken on arm64 as epoll_wait and thus __NR_epoll_wait doesn't exists. The patch assumes that if __NR_epoll_pwait2 is defined __NR_epoll_wait will be as well. This is in general not true.

I have a patch for this that should work.

Assignee: nobody → jld

Note that this can't easily be unit-tested, because the tests can't
distinguish between the real ENOSYS from lack of kernel support and
the fake ENOSYS from the sandbox.

Pushed by gpascutto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ad8cfda2ed0c Update Linux sandbox syscall defs to v6.8. r=gcp https://hg.mozilla.org/integration/autoland/rev/72b15a00b128 Update sandbox policies for `epoll_pwait2`. r=gcp
Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: