5 ms·

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

by comex 12y ago

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.

taeric 12y ago
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.
- sebcat 12y ago
  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.
  - strcat 12y ago
    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...
gsnedders 12y ago
Chrome did? IE7 shipped with pretty tight sandboxing in 2006 — and Chrome was only announced in 2008!
- yuhong 12y ago
  Only on Vista and later though.
- greggman 12y ago
  well let's see. in 2014 there were 214 code exploits in IE vs 4 in Chrome. I don't think IE's sandbox can really be considered tight http://www.cvedetails.com/product/9900/Microsoft-Internet-Explorer.html?vendor_id=26 http://www.cvedetails.com/product/9900/Microsoft-Internet-Ex... http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
  - throwawaykf05 12y ago
    Still doesn't change the fact that Chrome did not "pioneer" sandboxing.
    - xeromal 12y ago
      If the pioneer dies before he gets to california, he doesn't get the credit.
- strcat 12y ago
  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.
honestthrowaway 12y ago
Google invented sandboxing in client apps? I don't know who's more arrogant - Google or their fawning fanboys.
- delroth 12y ago
  Calling comex a "fawning fanboy"? That's ballsy for a throwaway account.
  - honestthrowaway 12y ago
    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.
    - yuhong 12y ago
      But do you know who comex is? People sometimes are not exactly precise and sometimes make mistakes too.
      - frankzinger 12y ago
        But do you know who comex is? I didn't, and it was not that easy to find out, but I was curious. He is Nicholas Allegra and he is known for jailbreaking the iPhone. See http://www.androidbeat.com/2013/04/google-comex/ http://www.androidbeat.com/2013/04/google-comex/ and http://www.forbes.com/sites/andygreenberg/2011/08/01/meet-comex-the-iphone-uber-hacker-who-keeps-outsmarting-apple/ http://www.forbes.com/sites/andygreenberg/2011/08/01/meet-co.... He went on to work for Apple and now for Google, apparently on the Chome or Chrome OS teams.
        Apofis 12y ago
        Damn, now honestthrowaway looks even more foolish. I can understand why he used a throwaway now.
    - 12y ago
zobzu 12y ago
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..)
- vanzard 12y ago
  What comex meant is Chrome pioneered the use of seccomp-bpf. And indeed, Chrome is by far the application using seccomp-bpf in the most advanced way.
- strcat 12y ago
  > 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.
  - zobzu 12y ago
    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. So no, I'm not confused :)
- pacala 12y ago
  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 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 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 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.".

by comex 12y ago

taeric 12y ago

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.

sebcat 12y ago
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.
- strcat 12y ago
  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...

gsnedders 12y ago

Chrome did? IE7 shipped with pretty tight sandboxing in 2006 — and Chrome was only announced in 2008!

yuhong 12y ago
Only on Vista and later though.
greggman 12y ago
well let's see. in 2014 there were 214 code exploits in IE vs 4 in Chrome. I don't think IE's sandbox can really be considered tight http://www.cvedetails.com/product/9900/Microsoft-Internet-Explorer.html?vendor_id=26 http://www.cvedetails.com/product/9900/Microsoft-Internet-Ex... http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
- throwawaykf05 12y ago
  Still doesn't change the fact that Chrome did not "pioneer" sandboxing.
  - xeromal 12y ago
    If the pioneer dies before he gets to california, he doesn't get the credit.
strcat 12y ago
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.

honestthrowaway 12y ago

Google invented sandboxing in client apps? I don't know who's more arrogant - Google or their fawning fanboys.

delroth 12y ago
Calling comex a "fawning fanboy"? That's ballsy for a throwaway account.
- honestthrowaway 12y ago
  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.
  - yuhong 12y ago
    But do you know who comex is? People sometimes are not exactly precise and sometimes make mistakes too.
    - frankzinger 12y ago
      But do you know who comex is? I didn't, and it was not that easy to find out, but I was curious. He is Nicholas Allegra and he is known for jailbreaking the iPhone. See http://www.androidbeat.com/2013/04/google-comex/ http://www.androidbeat.com/2013/04/google-comex/ and http://www.forbes.com/sites/andygreenberg/2011/08/01/meet-comex-the-iphone-uber-hacker-who-keeps-outsmarting-apple/ http://www.forbes.com/sites/andygreenberg/2011/08/01/meet-co.... He went on to work for Apple and now for Google, apparently on the Chome or Chrome OS teams.
      - Apofis 12y ago
        Damn, now honestthrowaway looks even more foolish. I can understand why he used a throwaway now.
  - 12y ago

zobzu 12y ago

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

vanzard 12y ago
What comex meant is Chrome pioneered the use of seccomp-bpf. And indeed, Chrome is by far the application using seccomp-bpf in the most advanced way.
strcat 12y ago
> 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.
- zobzu 12y ago
  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. So no, I'm not confused :)
pacala 12y ago
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 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 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 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.".