Closed
Bug 1120045
Opened 10 years ago
Closed 10 years ago
Pref off bug 1074561 and disallow unsandboxed media plugins by default
Categories
(Core :: Security: Process Sandboxing, defect)
Tracking
()
RESOLVED
FIXED
mozilla38
People
(Reporter: jld, Assigned: jld)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
We're having some second thoughts about bug 1074561, which allowed Linux systems without seccomp-bpf support to run OpenH264 (or, more generally, non-EME media plugins) unsandboxed. Specifically, it means that if a security vulnerability is found in OpenH264 (e.g., CVE-2014-8001 / CVE-2014-8002) and we need to rate its severity with respect to Firefox, we can depend on the fact that it's sandboxed… except on a few percent of Linux desktops (i.e., perhaps one in a thousand Firefoxes).
The current plan is to disable that by default, but allow a sufficiently advanced user to override it. A pref in about:config to select whether sandboxing is required or best-effort (sandboxed if supported, run without sandboxing otherwise), and defaulting to required, should be enough.
Assignee | ||
Comment 1•10 years ago
|
||
Move process sandboxing bugs to the new Bugzilla component.
(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)
Component: Security → Security: Process Sandboxing
Assignee | ||
Comment 2•10 years ago
|
||
This disables by default the part of bug 1074561 that allows unsandboxed media plugins; the check for unsandboxed CDMs is left unchanged, meaning that they are disallowed regardless of this pref (as mentioned in a code comment and the commit message).
I've tested this locally — I don't know if there's a good way to run tests that require starting Gecko with non-default prefs? — and pushed to try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1ab7104b218
Attachment #8553788 -
Flags: review?(rjesup)
Updated•10 years ago
|
Attachment #8553788 -
Flags: review?(rjesup) → review+
Assignee | ||
Comment 3•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment 5•10 years ago
|
||
Here's a thought: BSDs or non-i386/non-x86-64 don't have MOZ_GMP_SANDBOX enabled. Yet they can't benefit from this pref.
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #5)
> Here's a thought: BSDs or non-i386/non-x86-64 don't have MOZ_GMP_SANDBOX
> enabled. Yet they can't benefit from this pref.
That's a good point. The question of whether OpenH264 (or clearkey EME) should be allowed on --disable-gmp-sandbox platforms belongs to the WebRTC module owner, I think?
One complication is that the MOZ_DISABLE_GMP_SANDBOX env var should also disable the requirement of sandboxing — it wouldn't be very useful otherwise — so this would need to distinguish:
1. not available on platform (deny?)
2. available but disabled by user (allow)
3. available on platform but not on this particular system (deny)
4. usable (allow)
Currently cases 1 and 2 are conflated (and, by comparison, Windows and Mac OS X don't have to deal with case 3 or case 1).
Flags: needinfo?(rjesup)
Comment 7•10 years ago
|
||
Seems straightforward, unless I'm missing something:
1. Platform or system that doesn't support sandboxing (BSD, etc):
Default: disallow GMP (all)
pref set: allow unsandboxed GMP/OpenH264 (but not CDMs)
2. Platform/system does allow sandboxing:
Allow GMP (all)
Flags: needinfo?(rjesup)
You need to log in
before you can comment on or make changes to this bug.
Description
•