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)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: jld, Assigned: jld)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
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
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)
Attachment #8553788 - Flags: review?(rjesup) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
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.
(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)
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.

Attachment

General

Created:
Updated:
Size: