Closed Bug 1409895 Opened 2 years ago Closed 2 years ago

Do something about use of getcwd() in sandboxed content processes

Categories

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

Unspecified
Linux
enhancement

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox58 --- wontfix
firefox59 --- fixed

People

(Reporter: jld, Assigned: jld)

References

Details

(Whiteboard: sb+)

Attachments

(2 files)

I ran into some problems with media mochtests failing to find files when the content process was chroot()ed, even when most file access is brokered, and the stack trace pointed me at this[1]:

  var f = dirSvc.get("CurWorkD", Ci.nsIFile);

The test has some assumptions about what the working directory is, but it's been chdir()ed to its new root directory, so the path it constructs is wrong.

Ideally we'd stop depending on CurWorkD like that, but searchfox shows a lot of references to it, so maybe it'd be easier to intercept getcwd() with seccomp-bpf and return whatever the pre-sandboxing value was.

[1] https://searchfox.org/mozilla-central/rev/dca019c94bf3a840ed7ff50261483410cfece24f/dom/media/test/manifest.js#480
Priority: -- → P2
Assignee: nobody → jld
Whiteboard: sb+
I have a patch to simulate getcwd, but it might also work to change the dom/media tests in question to be chrome mochitests.  I'd rather not have to do a syscall interception if non-test code isn't using it.
Comment on attachment 8930310 [details]
Bug 1409895 - Make dom/media/test stop looking up CurWorkD in content.

https://reviewboard.mozilla.org/r/201450/#review208306
Attachment #8930310 - Flags: review?(cpearce) → review+
Comment on attachment 8930311 [details]
Bug 1409895 - Deny getcwd in the Linux content process sandbox.

https://reviewboard.mozilla.org/r/201452/#review211962
Attachment #8930311 - Flags: review?(gpascutto) → review+
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3194825c1f41
Make dom/media/test stop looking up CurWorkD in content. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/bc8fbf503fea
Disallow getcwd in Linux content process sandbox. r=gcp
The GTK theme parser seems to be trying to getcwd after the sandbox is started, but only in Talos for some reason, and I don't normally run Talos in Try.  I've taken the path of least resistance and made it fail with ENOENT, and this seems to work: https://treeherder.mozilla.org/#/jobs?repo=try&revision=54a67875e6df34bc99cc64747deb3d2833c6fab5
Flags: needinfo?(jld)
Attachment #8930311 - Flags: review+ → review?(gpascutto)
Comment on attachment 8930311 [details]
Bug 1409895 - Deny getcwd in the Linux content process sandbox.

https://reviewboard.mozilla.org/r/201452/#review212324
Attachment #8930311 - Flags: review?(gpascutto) → review+
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/519d3e54fda0
Make dom/media/test stop looking up CurWorkD in content. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/3b11a0bf7ae7
Deny getcwd in the Linux content process sandbox. r=gcp
https://hg.mozilla.org/mozilla-central/rev/519d3e54fda0
https://hg.mozilla.org/mozilla-central/rev/3b11a0bf7ae7
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Too late for Beta58. Mark 58 won't fix.
(In reply to Gerry Chang [:gchang] from comment #14)
> Too late for Beta58. Mark 58 won't fix.

Sorry; I should've untagged this from 58.  (It's a problem only because it blocks bug 1213998, so there'd be no point to uplifting.)
You need to log in before you can comment on or make changes to this bug.