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..)

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.".

I'm not sure why I'm even replying sometimes.

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.

So no, I'm not confused :)

http://www.cvedetails.com/product/9900/Microsoft-Internet-Ex...

http://www.cvedetails.com/product/15031/Google-Chrome.html?v...

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.

  But do you know who comex is?

If web pages were content to showing web sites, the vast majority of the motivation for heavy sandboxing, Chrome style, would be irrelevant.

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...

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.

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.

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)

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.

This is not so minor.

If they start handing out hundred dollar bills I would think they'd gone nuts.

I assume they'll either drop support altogether or will support RHEL 7 until RHEL 8 is shipped like they did with RHEL 6.

They don't care that most people don't jump ship and upgrade RHEL as soon as a new release exists.