Slashdot Mirror
Google Chrome Requires TSYNC Support Under Linux
An anonymous reader writes Google's Chrome/Chromium web browser does not support slightly older versions of the Linux kernel anymore. Linux 3.17 is now the minimum requirement. According to a thread on the Debian mailing list, a kernel feature called TSYNC is what makes the difference. When a backported patch for the Debian 8 kernel was requested, there were hostile replies about not wanting to support "Google spyware."
This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?
I thought T'Sync was Spock's aunt.
Would have been nice if TFS had included an explanation of what the TSYNC feature is.
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
So, you tell us you are not going to use a system that you weren't going to use.
And we should give a fuck, why?
Watch this Heartland Institute video
Debian 8 was a lost cause long before this nonsense. It will be the first "stable" version of Debian to include systemd. Systemd was forced upon Debian users thanks to some dirty politics, and has generally been unwanted by most of the Debian community. It already caused numerous problems for those running the unstable and testing versions of Debian, including systems that would no longer boot. The fact that systemd is still under very heavily development additionally means that it has no place in a stable Linux distro release, especially a Debian stable release. Many Debian users, especially those running servers, have realized that they need to discard Debian in order to maintain the stability of their systems. We've seen lots of these people move to the BSDs, in fact. All of that aside, Debian 8 is shaping up to be one of the most disappointing Debian releases ever, if not the worst, and it's all thanks to the bad decision to include systemd.
The general issue here is that running a fairly large, popular application now requires a kernel patch that was authored by the same organization that wrote the application. Moreover, the kernel version including this patch is well newer than what's shipped by most mainstream distributions, AND the application vendor is fairly hostile to running older versions of the application software (that wouldn't require this patch).
So,
1. Vendor isn't willing to think about distribution support timelines
2. Vendor doesn't seem to care about kernel/userspace boundaries and very happily writes code on both sides to an interface they've designed themselves, for themselves.
3. Profit?
Yes, doing it this way is notably easier for Google. This is generally considered one of the selling points of a closed ecosystem: you don't have to care about little things like public interfaces and what's already in the field (and going to be there for a decade): just "move fast and break stuff" because it all works in the environment that you're testing in, and you don't much care about anything else.
It's a detail of how sandboxing works on Linux. Other OSes have theirmown sandbox mechanisms. Microsoft cares about Windows having the necessary features because they use a sandbox in IE. The Linux sandbox mechanism that Chrome/Chromium uses appears to be an API at least partially developed by Google. TSYNC is a feature Google recently added to the sandboxing API in Linux because they intended to use it in Chrome.
This is really a non-issue. Chrome decided to use a recent feature in the kernel. This happens all the time. Most distributions that are using the older kernel have patched. If Debian doesn't want to patch, move to another distribution or switch to Firefox. Both Fedora 20 and 21 are on 3.17 - so it isn't an issue there. Debian is notorious for using old stuff, so it may be the kernel they are using requires a multitude of changes and because of their policies they don't want to move to a more recent version. You buy into that logic when you choose to use Debian - so expect this stuff to happen. This has nothing to do with RMS or Google; rather the mismatch of using a slow to update distribution with a browser that is on the fast track.
Chrome is by definition, spyware.
It does everything in its power to relay information about your activities back to Google, right down to what you click and when, if you allow it.
Most of these 'features' require you to opt-in, but some just happen right out of the box.
If you don't realize that the entire existence of Chrome and Chromium is to get information about you, you're an idiot with your head in the sand.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You know what? I'm not paranoid about Google. They don't care about me individually, and I opt out of their ad targeting. The rest I just don't care about.
You're can't be paranoid about google, paranoia is thinking that someone's watching you, with Google, they boldly state they're watching you and in your case you're aware of that. I personally do care what Google knows and have taken steps to limit that significantly, by using as little of their services as possible and making tracking me much more difficult. A random Jane or John at Google shouldn't be able to tell you you're on your period this week, for instance.
The cesspool just got a check and balance.
"TSYNC is a new sandboxing flag for seccomp that was recently added to the Linux kernel." -- from the description of the change to Chromium
Sounds like more browsers should be using it.
Disinfect the GNU General Public Virus!
Here is the kernel commit message:
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.
This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.
When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, ...) has been set on the calling thread, no_new_privs will be set for
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.
The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.
Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.
Changes across threads to the filter pointer includes a barrier.
https://git.kernel.org/cgit/li...
New things are always on the horizon
It means it makes Chrome more secure.
This sort of thing is why Debian is so often seen as a realm of knee jerk lunatics. Debian isn't keeping up with features Chrome needs to be more resistant to browser exploits (which are used to install ACTUAL spyware) and the answer is "Chrome gathers statistics on how it's used so it's evil and we don't care if it breaks". WTF?
This needs some serious modding up. ... as a lead developer who was instrumental in moving us from debian (which until the last year or two, I had been evangelizing and supporting for almost a decade) to FreeBSD for over 10,000 servers (two entire clusters) and hundreds of workstations (test/dev machines of developers/scientists/etc).
We're starting to see similar things from our peers as well, debian/centos/rhel/ubuntu being dropped pretty rapidly within our circle of influence - they don't listen to users/customers (really bad RHEL wise, when you're paying them hundreds of thousands of dollars), they fail on security (something debian was once great at), and they're moving linux into a direction that's frankly - undesirable for serious servers, HPC, etc.
Debian is dead, stop giving it attention, we've all moved on - so should the conversations.