What are we doing with getdents / directory file descriptors for desktop content sandboxing?

RESOLVED FIXED

Status

()

Core
Security: Process Sandboxing
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: jld, Assigned: jld)

Tracking

Trunk
Unspecified
Linux
Points:
---

Firefox Tracking Flags

(firefox51 affected)

Details

(Whiteboard: sblc4)

(Assignee)

Description

2 years ago
We need to investigate whether content processes on desktop Linux ever need to hold directory file descriptors.

If they do, then we need to make absolutely sure they can't do anything like openat() or fchdir() that might allow looking up ".." and walking to arbitrary files.  (This was a sandbox escape for Chromium in the pre-seccomp era: https://crbug.com/43304.)  This shouldn't be too much of a problem because we'll be brokering those syscalls anyway (and we already don't allow chdir or fchdir).  But there's also a question about whether there's some other syscall that's dangerous in the presence of directory fds that we didn't catch; the principle of least privilege applies here.

If they don't, then we don't need to be allowing getdents/getdents64 like we currently are.  But I suspect we'll run into things like system libraries scanning for plugins, like we did on B2G (bug 1078971).

A Try run with getdents blocked should be enough to get an idea of where we stand with this.

Updated

2 years ago
Whiteboard: sblc3
for investigation
Whiteboard: sblc3 → sblc4
(Assignee)

Comment 2

a year ago
ni? me to do a Try run.
Flags: needinfo?(jld)
(Assignee)

Comment 3

a year ago
Here's a try run with getdents blocked: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b57d8943042e137aa92207ac0205e108d3bfe473

*Lots* of stuff breaks (174 failed test jobs and rising as I type this); there appear to be several module loaders involved, from various parts of the widget toolkit and its support libraries, and the Web Platform tests break so early that the test automation gets messed up somehow and doesn't analyze the crash dump.

So the answer is probably that we're stuck with the content process holding directory descriptors, and we'll be completely dependent on the seccomp-bpf policy to prevent using them for path traversal attacks or whatever else, even on systems where we can also use namespace/chroot sandboxing.
Flags: needinfo?(jld)
(Assignee)

Comment 4

a year ago
The answer seems to be that directory fds and getdents in the content process probably aren't ever going away, and certainly aren't going anywhere in the foreseeable future.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.