Really, a browser is now dependent on a particular Linux kernel?
For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10...
Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.
Chrome isn't your average application, though - it pioneered the modern use of tight process sandboxes in general (in client-side applications, anyway), and in particular was the biggest motivating client for (and Kees Cook on Chrome OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old sandboxing mechanism that allows precise control of permitted syscalls and syscall arguments. The incompatibility here is related to a new seccomp feature. I don't know whether it's reasonable to drop support for older kernels, but it's no surprise that Chrome is using the latest and greatest in kernel sandboxing support.
Chrome certainly didn't pioneer anything. Google devs brought seccomp-bpf to the kernel, which is a simpler alternative (but also not always as useable) to many other mechanisms.
Chrome is one of the first products on linux with a large amount of users to support a reasonably strong sandbox. But that's not what pioneering means.
Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)
There is no stable sandboxed browser protecting against kernel vulnerabilities on any platform that I know of prior to Chrome. That's the very definition of pioneering. Do you have an example of prior art? There may be sandboxing mechanisms in various kernels, but that's not what browser users care about.
As for the other points:
* "seccomp-nonbpf" is a vastly more limited mechanism than seccomp-bfp, and inappropriate for Chrome use-case. http://en.wikipedia.org/wiki/Seccomp. seccomp-bfp is pioneering in Linux kernel space, even if, ironically, the team might not have wanted to spend their time there. See below.
* Popular consumer distribution of Linux doesn't have SELinux enabled by default. https://wiki.ubuntu.com/SELinux. "SELinux can be enabled in Ubuntu by installing the "selinux" meta-package". In my bubble we everyone uses Ubuntu on desktop, apologies to other distributions vying for the title of "popular consumer Linux distribution".
* Not sure why we are talking about security mechanisms on non-Linux kernels. Chrome is a browser, the team's job is not to innovate in the kernel space. http://www.chromium.org/developers/design-documents/sandbox. "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".
if you give enough details you'll always find a way to work around words.
For example if i ship a copy of webkit with my ui on top with a sandbox I'll pioneer that. Or a shell. Or a text editor. Or whatever you want. A blue wheel of 29.0349in on a bike. etc.
> Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)
You're quite confused. SELinux, AppArmor, SMACK, etc. do not overlap with seccomp-bpf which exists to protect the kernel itself. Chromium has a working sandbox with or without seccomp-bpf based on a chroot, namespaces and IPC protocols. It needs seccomp to mitigate kernel vulnerabilities, which are not at all uncommon.
they actually do the control in a very similar way. its the model of how the control is decided that differs.
in other words, they're all blocking syscalls depending on the arguments/syscall name/etc. LSMs and seccomp-bpf alike.
There is no Windows sandbox (including the Chromium one) that's comparable to the quality of Chromium's Linux implementation.
Note that seccomp is a layer on top of the layer-1 sandbox implementation based on a chroot and namespaces. There is no equivalent to the layer-2 sandbox used to protect against kernel vulnerabilities on other platforms.
Google created seccomp-bpf which is crucial to a meaningful sandbox and has no equivalent on other platforms. It was not an obvious innovation or it would have been done years earlier. It exists because someone paid by Google to improve Chromium security had the epiphany that BPF would be a good way to filter system calls.
Claiming that Chrome pioneered sandboxing doesn't pass the smell test, irrespective of how many Google employees (according to your profile) are backing you up.
On the flip side, chrome is also one of the tools used to convince people that web should somehow be equivalent to native. Which, really, just doesn't make any bloody sense.
If web pages were content to showing web sites, the vast majority of the motivation for heavy sandboxing, Chrome style, would be irrelevant.
You have code running on your computer for rendering the content. Historically, pictures (GDI+ buffer overflow, and others) and .pdf files has been used for exploiting bugs in that code. Sandboxing would have made that a non-issue, or at least less severe of an issue.
It's still a serious issue even with a sandbox, both because of the endless stream of kernel vulnerabilities and similar issues in userspace processes the sandboxed processes communicate with to get work done.
Chromium's use of seccomp-bpf is solely to crack down on kernel vulnerabilities, as it's an additional layer over a sandbox already providing all of the security boundaries they need. It moves things along pretty far, but there are still at least 1-2 holes found every year.
It's definitely an improvement over browsers like Firefox where there are at least 3-4 unmitigated remote code execution vulnerabilities fixed every six week cycle...
When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.
Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall.
> When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.
OTOH, when you make a break-the-world release every six weeks, you can expect lots of breakage when dealing with the rest of the world. From what I can tell, Google pushed a feature they wanted into Linux, then didn't bother to think about backward compatibility. This would be fine if Chrome weren't force-updating software -- people on older kernels could just wait and update when they updated their kernels -- but alas that is not the case.
"Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall."
Yes, it is a good thing for the people who 1) use desktop linux and 2) use a rolling distribution or a distribution that was released within the last year. I suspect that might be a rather small percentage of the Desktop users in the world.
It simply means that people who 1) use a desktop Linux and 2) use a stable distribution can't run Chrome (which I imagine solves the security problem in another way). This fraction of a fraction may be larger (corporate desktops, e.g. RHEL, CentOS, Scientific Linux, Debian stable, Ubuntu LTS &c)
Google does a lot of Linux kernel work, a lot of gcc work, a lot of clang work, open-sources monumental amounts of code, pays several hundred students to work on open-source during summer.
If that's not enough to "generate a ton of good will" then doing one more minor thing won't change anything.
If they start giving out hundred dollar bills, you'll be complaining that it's not two hundred dollar bills.
I'm aware of the work they do. A couple of stupid decisions can cancel out a lot of good will. Not back-porting key pieces of tech and sunsetting products without open-sourcing them is going to counteract the good will they generate. I actually don't dislike Google, and appreciate that they've been a decent open-source player.
This is not so minor.
If they start handing out hundred dollar bills I would think they'd gone nuts.
I don't think the Chrome dev team would want to drop earlier kernels that easily, but this option must help development a lot. From looking, it seems to be something regarding synchronising SECCOMP filters between different threads (SECCOMP is a security sandbox). I imagine this removes quite a bit of code, or fixes some serious corner cases.
For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10...
Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.