101–110 of 139 posts
Earlier quoted context omitted.
Chrome did? IE7 shipped with pretty tight sandboxing in 2006 — and Chrome was only announced in 2008!
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-Ex... http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
Earlier quoted context omitted.
7 months is too short, but 10 years is too long to go for a workstation, which is where Chrome would be used.
What about Windows XP? It still holds more than 50% Chinese market.
Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a bug that caused installing extensions to fail with that kernel, and then declined to fix it. https://code.google.com/p/chromium/issues/detail?id=401655 See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix…
Earlier quoted context omitted.
At least there seems to be a supported method for updating the 14.04 kernel: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware... Apparently, Ubuntu 14.04.2 installs a 3.16 kernel by default, and previous 14.04 installs can be updated by installing a bunch of "*-utopic" packages.
This seems like a colossal mess waiting to happen. I'm glad that I read their plan, so that I can completely avoid it. The allure of Ubuntu LTS releases (currently 12.04 and 14.04) is the extended support cycle -- practically speaking the kernel is the biggest component of this for a lot of people. If you use the 3.16 kernel (from Ubuntu 14.10) on 14.04, you are now on a 6 month support cycle [1]. One which doesn't e…
Really? I mean, step back from your initial gut reaction and ask yourself how many software developers could even name which version of the kernel their code runs on without checking. Most developers never make a syscall directly and, increasingly, aren't even calling something like libc directly because they use higher-level libraries.
Sure, some people really care cause they recently hit an issue with specific drivers and a few people are using a really new feature, but that's a much smaller group than the number of people running code which doesn't even depend on Linux, much less a specific point release.
Looking at the release notes, I'd say there are a LOT more people affected by real bugs which are fixed in 14.04.2 than will be affected by hypothetical bugs nobody seems to have noticed yet:
https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummar...
Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a bug that caused installing extensions to fail with that kernel, and then declined to fix it. https://code.google.com/p/chromium/issues/detail?id=401655 See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix…
Happily there's an even more reasonable workaround of upgrading to a browser that doesn't dictate kernel versions.
There's a feature of the kernel that Chromium wants to use. That's a perfectly good reason to upgrade.
User software should dictate kernel versions.
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 usua…
Earlier quoted context omitted.
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-Ex... http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
Still doesn't change the fact that Chrome did not "pioneer" sandboxing.
Earlier quoted context omitted.
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 her…
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…
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.
Earlier quoted context omitted.
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 her…
Chrome did? IE7 shipped with pretty tight sandboxing in 2006 — and Chrome was only announced in 2008!
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.