Closed
Bug 1409895
Opened 7 years ago
Closed 6 years ago
Do something about use of getcwd() in sandboxed content processes
Categories
(Core :: Security: Process Sandboxing, enhancement, P2)
Tracking
()
RESOLVED
FIXED
mozilla59
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
Updated•7 years ago
|
Priority: -- → P2
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jld
Updated•7 years ago
|
Whiteboard: sb+
Assignee | ||
Comment 1•7 years ago
|
||
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 hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 4•6 years ago
|
||
mozreview-review |
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 5•6 years ago
|
||
mozreview-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
Comment 7•6 years ago
|
||
Backed out 2 changesets (bug 1409895) for crashes in Linux talos jobs r=backout on a CLOSED TREE https://hg.mozilla.org/integration/autoland/rev/e056256f34337a7d20eff986b69e4791135f10b3 https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=bc8fbf503fea22d3db9d44a2e79e440c6c86490a&filter-resultStatus=usercancel&filter-resultStatus=runnable&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception
Flags: needinfo?(jld)
Assignee | ||
Comment 8•6 years ago
|
||
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)
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Updated•6 years ago
|
Attachment #8930311 -
Flags: review+ → review?(gpascutto)
Comment 11•6 years ago
|
||
mozreview-review |
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+
Comment 12•6 years ago
|
||
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
Comment 13•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/519d3e54fda0 https://hg.mozilla.org/mozilla-central/rev/3b11a0bf7ae7
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Comment 14•6 years ago
|
||
Too late for Beta58. Mark 58 won't fix.
Assignee | ||
Comment 15•6 years ago
|
||
(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.
Description
•