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."
It's not the "TSYNC feature", it's SECCOMP_FILTER_FLAG_TSYNC
http://lkml.iu.edu/hypermail/linux/kernel/1406.1/01964.html
(Buggered if I know what it's for, however).
Watch this Heartland Institute video
Digging around a bit this is what I gathered:
TSYNC is some flag added to seccomp to aid in something relating to thread synchronization: http://patchwork.linux-mips.or...
And seccomp is a security mechanism of the Linux kernel used to implement the sandbox in Google Chrome, which it uses for instance to run the Flash plugin in such a way that it doesn't compromise the system if one of its many security weaknesses: http://lwn.net/Articles/347547...
None of this seems to have any relation to spyware, in fact it would seem to have the exact contrary purpose: protecting the system from potentially malicious code and security exploits.
Unless I'm missing something obvious, it sounds like Ben Hutchins (the Debian mailing list guy who made the comment on spyware) just dislikes Chrome for whatever reason unrelated to TSYNC and decided that it would be a fine way to ensure new versions of Chrome don't run.
It's not a bug. Google's Chromium team decided the Linux kernel seccomp API wasn't meeting their needs, so they added the TSYNC feature (which makes applying seccomp sandboxing to child threads easier to do securely) to the kernel so they could use it in their code. They just aren't caring about the fact that not a lot of users have good reasons to be running older kernels. And it's complicated by the fact that they didn't get the kernel feature in before Debian jessie's feature freeze. Once again because they don't seem to care about other people's software lifecycles.
It's part of the "sandboxing" mechanism in Linux which allows processes to limit their interactions with the kernel to a subset of API calls by installing filter programs. The purpose of this limitation is known as the concept of least privilege: A process should not have more power to do anything than it needs to do its job. If it has more power, then an attacker can use that power in case he achieves control over that process. That's why you don't run your web server as the root user, for example. Server processes often start as high-privilege processes (for example to be able to attach to network ports lower than 1024), and then shed their privileges by switching to a limited user. Seccomp is a more fine-grained way of limiting the powers of processes. If a process tries to use a kernel API that it has previously denied itself access to, the kernel kills the process. For example, a process which in its normal operation never needs to access the file system can install a filter program which denies it all access to the file system API of the kernel. If an attacker injects code into the process to access the file system, the API call will then get the process killed instead of accessing the file system. The TSYNC feature enables a process to refine (limit more) whatever limited access a group of threads previously had (TSYNC stands for thread synchronization).
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.
Right, so here is seems how things are:
1. Google seems to have little regard for long term backwards compatibility, at least on the timeframes Debian wants it. Kernel 3.17 came out in October 2014. Fedora has a new enough kernel, but also doesn't have Chromium officially apparently because Google likes to clone various libraries and do API changes, rather than trying to work with the original developers, distributions, etc. So it seems Google mostly does its own thing and lets other people to deal with it.
2. So Google is now releasing browsers that require kernel 3.17 to work properly. Users want to run it on their systems.
3. But Jessie is frozen and so changes only happen for good reasons. The question is then whether to backport the TSYNC feature. On one hand, it's a new feature and it doesn't go in frozen releases, on the other hand it stops new versions of Chrome from running, which is a security concern. Ubuntu seems to have went with the later logic.
4. Ben's reaction is "1. I don't like Chrome, so no", and "2. Distro is in freeze, there needs to be a formal proposal explaining exactly what patch to merge, and a sympathetic maintainer, which I am not".
So really what's going on is a conflict between organizations. Google wants to move faster than Debian does, and Debian (or at least Ben) doesn't want to give Google special concessions.
Chrome decided to use a recent feature THAT THE CHROME DEVS SUBMITTED TO THE KERNEL ... and isn't in any distribution that matters ... nor will it be for some time to come.
The issue is that unless your running a dev/unstable branch, you aren't going to have this kernel feature and you're not going to have it in stable/LTS versions ever ...
The application dropped support for production kernels ... because it wants a patch that isn't yet in production kernels.
Googles foot ... they just shot a hole in it, fuck'em.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Ubuntu already appears to have a seccomp-tsync backport to 3.16.x: https://lists.ubuntu.com/archi....
I do dislike Chrome and I'm not going to pretend otherwise. Aside from its being spyware (in its default configuration), the Chrome/Chromium developers have previously added requirements that make Chromium unsupportable in Debian 7. We could add this kernel feature now, but I strongly doubt that will be sufficient to keep Chrome/Chromium running on Debian 8 until its EOL.
Please note that I am not NAKing the change, but I'm also not going to be the one to make it happen.
The sad thing is that Mozilla hides their ESR release. Once I (unsuccessfully) tried to find it on mozilla.org (Go ahead, try it!).
I only succeeded by using Google (oh, the irony!) to find an obscure download page on mozilla.org.
Mozilla treats their ESR release like some unwanted stepchild.
No, you're not SOL - there is a thriving community of Chrome hackers who change anything and everything they don't like about Chrome.
http://www.srware.net/en/softw...
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
No systemd is not production ready. I've Debian testing systems in vm, and find systemd is buggy garbage.
If the process does something that it promised not to do, it can't be trusted anymore and must not be allowed to continue. The first attempt to use an unauthorized API seals its fate. The server or application can just spawn a new process.
"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!
The issue not google chrome, but SystemD bloatfest
The patch was committed in July, and Jessie's freeze started on the Nov. 5th.
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?
That'll be https://www.mozilla.org/en-US/firefox/organizations/all/.
Sadly, despite being a long-term FF user, it pains me to say it's far easier is to switch to Palemoon; it's a minimal effort and the result is firefox without all the BS (Palemoon being a firefox fork/tracker that values functionality over hipster cool)
All your ghosts are just false positives.