1039819 - Can we depend on seccomp-bpf for Linux desktop sandboxing?

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

EME CDM sandboxing is an actual feature we've promised to users (see https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/ ), so it's important to know whether we can depend on users' Linux distributions to have support for seccomp-bpf.

Current status of a few distributions:

  Ubuntu: since 12.04 LTS ("Precise Pangolin"). [3]
  Debian: not in wheezy (7.x), which is the current stable release; in testing and unstable, so will be in 8.0. [4]
  RedHat/CentOS: since 7.0 (released 2014-06). [5][6]
  Fedora: since version 18 (released 2013-01). [7]

Which leaves us with some questions:

1. How much of the Linux desktop userbase is on a seccomp-bpf-enabled distribution?  Should we do a telemetry experiment to try to estimate it?  (And, if so, to what extent is a sample of nightly/aurora users representative?  Would they also tend to be disproportionately running newer or prerelease OS versions?)

2. What do we do if seccomp-bpf isn't supported?  Refusing to run the CDM at all seems user-hostile.  Expecting the user to understand the implications of sandboxing and make an informed decision about whether to risk running the CDM unsandboxed seems like a very bad idea.  Integrating the Chromium setuid sandbox, which would work on more systems (but which Chromium itself is trying to get away from, if I understand correctly), hasn't even been considered up to this point and may be difficult.


[3]: http://www.outflux.net/blog/archives/2012/03/22/seccomp-filter-now-in-ubuntu/
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675615
[5]: http://www.redhat.com/about/news/archive/2013/12/red-hat-announces-availability-of-red-hat-enterprise-linux-7-beta (kernel 3.10 is new enough)
[6]: http://vault.centos.org/6.5/updates/Source/SPackages/kernel-2.6.32-431.20.3.el6.src.rpm (unroll the kernel source and look at the switch statement in kernel/seccomp.c)
[7]: https://fedoraproject.org/wiki/Features/Syscall_Filters

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Could we use telemetry for this?

The simplest test I know of is to call prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0); i.e., try to set a filter but pass a null pointer.  In either case it fails with no side effects; errno is set to EFAULT if seccomp-bpf is supported, EINVAL otherwise.  Or, using js-ctypes: https://pastebin.mozilla.org/5569501

Comment 2

[Benjamin Smedberg]

I am surprised that we're not using the chromium sandbox. Last I was involved with this discussion integrating the chromium sandbox was our strategy for all platforms.

I don't see any problem with adding a telemetry probe for this. I expect that you'll get the most useful answer from the beta population, so you may want to uplift this to get faster data.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Benjamin Smedberg  [:bsmedberg] Away 19-July through 3-Aug from comment #2)
> I am surprised that we're not using the chromium sandbox. Last I was
> involved with this discussion integrating the chromium sandbox was our
> strategy for all platforms.

This is a little complicated.  There are two layers to the Chromium sandbox on Linux:

1. The setuid sandbox, which we're not using (yet?), which requires shipping a setuid-root executable in order to use chroot(2) and to create separate process/network namespaces — which means it's no longer possible to build and run (or install) Firefox without root permissions, or else the sandbox won't work.  On the plus side, any Linux new enough to run Firefox at all should be able to use it.

2. The seccomp-bpf system call filter, which we are using, and which can be used from an unprivileged process, but requires kernel support that's not everywhere yet.

I'm told that the original idea, when the Chromium people designed all of this, was that layer 1 is to protect other processes and the user's data, and layer 2 is to protect the kernel against exploitation of bugs in system call interfaces that normally wouldn't be used.

But it's fuzzier than that, because if you can set a restrictive enough policy with seccomp-bpf then in principle it's possible to deny any kind of filesystem or network access (other than via descriptors passed in over IPC) just as effectively as with the setuid sandbox… as long as you don't miss anything, including little-known features of innocuous-looking system calls (e.g., clock_gettime can read other processes' CPU usage, apparently).

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The answer to the question in this bug's summary appears to be “no”.

With some help from the nice people of Metrics, I've collated the kernel version information collected by the Firefox Health Report: 35% of Linux desktop users have a kernel older than 3.5, which is where seccomp-bpf first landed. 

That number may shift somewhat by the time Firefox 36 (the earliest release that would have CDM support) is done riding the trains, and I should see if I can get a useful time series out of FHR to try to extrapolate, but if I had to guess right now, I doubt it will become small enough to consider not supporting EME on those systems.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #4)
> I should see if I can get a useful time series out of FHR to try to extrapolate

A simple logistic regression on date and Firefox version suggests that, when Firefox 36 is released, the proportion of users running it on pre-3.5 kernels will still be at least 20%.  At this point I think we need to assume we'll be using the setuid sandbox.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

It looks like I got this dramatically wrong due to misunderstanding Ubuntu's release management.  The relevent info is on https://wiki.ubuntu.com/Kernel/LTSEnablementStack; in particular:

> 6. Anyone running with the original Precise stack will not be automatically updated to the new Quantal enablement stack.

In other words, someone who installed Ubuntu 12.04.0 or 12.04.1 will continue to be upgraded to newer patch releases of Ubuntu's 3.2 kernel branch even though a fresh install of the resulting patchlevel would get a newer (>= 3.5) kernel.  Ubuntu's 3.2 branch has had backported seccomp-bpf since the beginning (confirmed by the package changelog), but it was omitted by my earlier searches because I incorrectly assumed it was obsolete.

So.  Restricting the search to FHR data from Firefox 30 during the time it was mozilla-release, 70% have kernels >= 3.5.  If we assume that versions of the form "3.2.0-NN-generic" for some number NN are Ubuntu, or even just when NN is reasonably close to its current value of 67, that adds around another 25%, for a total of 95%.

Also, somewhere between 1/3 and 1/2 of the remainder are on no-longer-supported versions of their distribution.
And the ~1.5% of Firefox users on Debian stable should have a seccomp-bpf-enabled release entering hard freeze at the same time as the Firefox 36 release (https://release.debian.org/jessie/freeze_policy.html).  (Iceweasel isn't part of these numbers because it doesn't submit data to FHR, but it also follows Debian's release cycle, so this kind of incompatibility would be limited to not-officially-supported backports.)

All things considered, I think the answer to this bug's question is actually "yes", in which case bug 1041885 can stop blocking EME.

Bonus fact: 60% of the Fx30 reports have kernels >= 3.10, which (as I understand it) means they should have CLONE_NEWUSER, which means they could use the "setuid" sandbox without needing an actual setuid root executable.

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

So we have about 4.5% of Linux desktop Firefox users who won't be able to use EME under the current plans (or would have to run it unsandboxed), and I'd like to confirm that that's okay.  To summarize the previous comment, that further breaks down as:

1.7%: on post-EOL[*] Ubuntu and should upgrade anyway
1.5%: Debian stable; won't be EOL, and next version might not be out before Linux EME
1.3%: other; might or might not be EOL, but upgrade is likely possible

(Disclaimer: FHR counts unique browser profiles and doesn't collect PII, so I'm making the assumption that the proportions are roughly reflective of the humans behind them.)


[*] For desktops; 10.04 is supported on servers until 2015-04, but servers probably wouldn't be running browsers needing EME, I think?

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Jed Davis [:jld] from comment #7)
> 1.7%: on post-EOL[*] Ubuntu and should upgrade anyway
> 1.5%: Debian stable; won't be EOL, and next version might not be out before
> Linux EME
> 1.3%: other; might or might not be EOL, but upgrade is likely possible

It doesn't make sense to delay getting the sandbox to 95.5% of Linux users for the sake of the remaining 4.5%.

Comment 9

[Maire Reavy [:mreavy]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #8)
> (In reply to Jed Davis [:jld] from comment #7)
> > 1.7%: on post-EOL[*] Ubuntu and should upgrade anyway
> > 1.5%: Debian stable; won't be EOL, and next version might not be out before
> > Linux EME
> > 1.3%: other; might or might not be EOL, but upgrade is likely possible
> 
> It doesn't make sense to delay getting the sandbox to 95.5% of Linux users
> for the sake of the remaining 4.5%.

Agreed.  95% for a first release is damn good.  Ship it!  :-)

Comment 10

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #7)
> 1.5%: Debian stable; won't be EOL, and next version might not be out before Linux EME

…but does have newer kernels available: https://packages.debian.org/wheezy-backports/kernel/ (backports, so "provided as-is", but no less supported using branded Firefox instead of Iceweasel, as I understand it).