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.
Whiteboard: sblc3 → sblc4
ni? me to do a Try run.
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.
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.