Google Chrome Requires TSYNC Support Under Linux 338
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."
So much for LTS releases (Score:2)
Re: (Score:2)
you can use the debian LTS version of chromium. Where is the problem?
Re: (Score:2)
Every package is not supported in the LTS distribution. Chromium for example is not supported.
Re: (Score:3)
Chromium is the opensource chrome, that's it. It does not have spyware and not the nasty habit of chrome to mess with your package manager to update by itself (i mean, really WTF?)
Re: (Score:2)
I tested HWE on a few test systems before rolling it out across the rest of my systems. Long story short, several of the test systems had intermittent networking problems after the upgrade, which caused the systems to hang until power-cycled.
In my environment, stability is more important than having the latest gee-whiz features, and due to slashed budgets, supporting new hardware is a problem I don't have, so it's not worth the trouble to try to use the Trusty kernel right now.
Doesn't smell right (Score:5, Insightful)
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?
Re: (Score:3)
well with chrome you would be shit out of luck to change it if google will not.
with chromium though there should be a patch... or maybe not. googles answer to their own projects has been to backport the patch.
Re:Doesn't smell right (Score:5, Informative)
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... [srware.net]
Re: (Score:2)
Chromium, not Chrome. There's a distinct difference between the two.
Re:Doesn't smell right (Score:5, Informative)
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.
Re: (Score:2, Informative)
The patch was committed in July, and Jessie's freeze started on the Nov. 5th.
Re: (Score:3)
OTOH they have NO REASON AT ALL to upgrade. Upgrades can get you into trouble, on kernel updates this means trouble with drivers (ups, i upgraded, now wlan is not working anymore), while staying with a matured kernel which only gets security patches is a good choice.
Re:Doesn't smell right (Score:5, Insightful)
People are only noticing now because Google recently announced that future versions of Chromium (and thus Chrome) will only work with kernels that have this flag. It's a silly controversy because a Debian kernel maintainer just categorically rejected adding the patch not on any technical merit, but simply because he doesn't like Google. And as far as rejecting the patch because the freeze, well, that doesn't really fly since this patch was offered back in October of last year. In fact, Ubuntu already backported the patch for 12.04 lts kernel (3.13) and higher. So its not as if Debian couldn't have added the patch before the freeze. Apparently, this patch is simply being rejected because of a pathetic personal animosity towards the developer of patch, or the company he works for (Google).
Re: (Score:2, Insightful)
LTS as a practice, is against Google's best interest - Google is attempting to leverage Chrome to turn all software into insecure, auto-update, phone home garbage - just like all other web applications. They don't want to use the workaround, they want you to update.
Re:How the fuck does Chrome handle other platforms (Score:5, Informative)
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.
Re: (Score:2)
Just because a version of Chrome gets released doesn't mean that all distributions will and must begin using the code immediately. Distributions will simply not deliver newer versions of Chrome until the kernel is bumped up to the level required to support said newer version.
Re: (Score:2)
Re: (Score:3, Funny)
I don't know what the fuck TSYNC is, but I'm confident that the BSDs, OS X, and Windows probably don't offer it, especially if only recent Linux kernel versions support it.
So how the flying fuck can Chrome run on these other systems that don't offer this functionality? What in shit's name is preventing those workarounds from being used on these older Linux systems?
Shorter AC: I have no fucking idea what this is all about, but it fucking enrages me! Raaaugh!
What's TSYNC ? (Score:5, Interesting)
Would have been nice if TFS had included an explanation of what the TSYNC feature is.
Re:What's TSYNC ? (Score:5, Informative)
It's not the "TSYNC feature", it's SECCOMP_FILTER_FLAG_TSYNC
http://lkml.iu.edu/hypermail/linux/kernel/1406.1/01964.html [iu.edu]
(Buggered if I know what it's for, however).
Re:What's TSYNC ? (Score:5, Informative)
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).
Re: (Score:2)
Thanks. If I understand your summary correctly, this sounds like a good security feature, apart from the "killing the process" bit. This seems like a handy mechanism for DOS attacks. Why not just refuse to do the unwanted thing and ignore it, while perhaps logging the attempt?
Re: (Score:2, Informative)
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.
Re: (Score:2)
This still doesn't explain why a userland program would require it? Is Chrome trying to foist the sandbox over on the kernel and relying on the kernel killing Chrome if the user installs an extension that isn't kosher?
If so, it would seem like a good way to get users to stop using Chrome, because there would be no indication that's understandable by a mere user of why the app suddenly quit. Or am I guessing wrong here?
Re: (Score:2)
You understand that allowing the rogue process to continue, as it would without the sandbox, means that you've been exploited successfully at that point, don't you?
No, that does not follow. Apps do things they shouldn't do without malice too. It may not be desirable, but it does not imply that there is any attacker who have exploited your system.
Re: (Score:2)
I for one hate trying to track oddities and buggy software down which is especially harder when there are no logs or evidence of the mibehavior.
Re: (Score:2)
I also thank you, Sir AC.
Re:What's TSYNC ? (Score:5, Informative)
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... [linux-mips.org]
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... [lwn.net]
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.
Re: (Score:3)
Now one can have his opinion and think that Chrome/Flash are evil incarnates and must be wiped out from our universe, that doesn't change the fact that Flash still exist, is still in use by an awful lot of websites, and Chrome is the only way to get this content under Linux. Telling people "na
Re:What's TSYNC ? (Score:5, Informative)
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 [debian.org]. 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.
Re: (Score:3)
Do you honestly think your vocal opposition would not stand in the way of another developer deciding to get it in?
Re: (Score:3)
Re:What's TSYNC ? (Score:5, Informative)
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.
Re: (Score:3)
it stops new versions of Chrome from running, which is a security concern.
if old versions of chrome become a security concern it's google's responsibility to either provide a fixes or at least effectively warn users, period. has nothing to do with any aspect of any os chrome happens to run on.
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.
it's much like you say but i see no conflict, really. google can have its way, and debian (ben) is just being consistent with being debian. users can have their pick so no problem. responsibility is still clearly outlined and any rogue chrome versions causing havoc will be chrome's fault, re
Re:What's TSYNC ? (Score:5, Insightful)
they were able to survive without TSYNC and make it 'safe' but suddenly they can't
Geez, improving their software's security by taking advantage of better kernel support, Google really are deadbeat stupid. Better drop the sandboxing idea, have everything in the same process, preferably run as root. We'll be all safe with this old, not up-to-date version of openssl with brand new SSL3.0 support.
Re: (Score:2)
This would be inconsistent with masses of people clicking into the discussion thread going "WTF?" and then sticking around to post a comment.
I'd quit Slashdot in a heartbeat (abandoning what limited loyalty remains) if I were willing to wade through the alternatives in search of an alternative forum in which the paragraph as a unit of discourse has not yet been un-invented.
Back in grade nine, back in the 1970s, in a school
Don't you compile your own browser? (Score:2)
Rather than adding new code to your kernel, why not simply remove new code (whatever breaks without this TSYNC) from your browser? If this code was recently added, it just can't be that difficult to remove.
You are compiling it yourself, aren't you? I certainly do — that's what source code [googleapis.com] is for. What's the problem?
Re: (Score:2)
That's what DOCUMENTATION is for. I'm no coder, but I can compile the stuff I want, the way I want it. Any coder watching me decipher code would want to cry - it would be like watching the special Olympics from his point of view. But, I can read the documentation, and pull shit out of the wall of text, or I can stick shit in, or I can just stir the shit a little bit. Try it some time.
Re: (Score:2)
So, where is the source code for Chrome? No, not Chromium. Chrome.
People are correctly annoyed by this (Score:5, Insightful)
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.
Re: (Score:3)
This would be a non-issue if Google supported some kind of ESR release, as Firefox has. i.e. Firefox is now at 36 but debian stable will ship with the 31.x ESR. (One can pull the 36.0 release from experimental if game)
Re:People are correctly annoyed by this (Score:4, Informative)
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.
Re:People are correctly annoyed by this (Score:5, Informative)
That'll be https://www.mozilla.org/en-US/firefox/organizations/all/ [mozilla.org].
Sadly, despite being a long-term FF user, it pains me to say it's far easier is to switch to Palemoon [palemoon.org]; 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)
Re: (Score:2)
Re: (Score:2)
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.
So, nothing ends up in Linux unless Linus lets it in, and it isn't like this was snuck in.
Really, Google is doing the right thing here. Instead of trying to hack inter-process security in on the userspace side, they're extending the kernel to improve things. Inter-process communications/relationships/etc is one of the things the kernel is supposed to do.
This is no more a violation of boundaries than putting modesetting in the kernel instead of running X11 as root and having it set device registers and suc
Re: (Score:2)
Don't forget that "feature" they added some months ago where the browser arbitrarily disables add-ons that weren't approved by the vendor, without the option for the user to white list them or explicitly enable them. They're just disabled, for your own good, stop asking questions. So now you're forced to run the "developer version" which allows this, and it aggressively updates itself to the latest version every chance it gets.
Re: (Score:3)
The feature added is something that is generally useful for a large number of network applications, not just Chrome. Its a sandbox feature that other programs and servers could benefit from, not just Chrome. Given the dangers of the web browser today, you basically shouldnt be running a browser without a sandbox, the security imperative is certainly justified enough for a backporting of the feature to older kernels to add the additional security.
Re: (Score:2)
So "The Google Way" is the correct way, and every other application in Linux is insecure?
Security isn't a binary thing. Google's way is more secure, and I'm sure other applications will start using it. It only hit the kernel a few months ago, don't be surprised if every single process on Linux is using it.
Re: (Score:3)
Its not bloatware. The feature is something that can be widely used by any networked program, it provides a security layer. Given the problems browsers have faced with security issues, its a badly needed extra layer of security. You are basically saying that protecting the system from an compromised process is bloatware. Thats nonsense. If anything, Firefox needs to play catch up to implement the sandbox.
Google Chrome is fast moving... (Score:5, Insightful)
Re:Google Chrome is fast moving... (Score:4, Informative)
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.
Re:Google Chrome is fast moving... (Score:4, Insightful)
Re:Google Chrome is fast moving... (Score:5, Insightful)
The application dropped support for production kernels ... because it wants a patch that isn't yet in production kernels.
The feature is in several stable kernel branches. Your distro might just not support them, so either don't use Chrome, or don't use that distro, or figure out how to use a newer kernel on your distro. :)
Re:Google Chrome is fast moving... (Score:5, Insightful)
THAT THE CHROME DEVS SUBMITTED TO THE KERNEL
Putting something in bold doesn't in any way make it relevant. Chrome devs didn't put it into the kernel, they submitted it as you said. There's a whole team that look after and maintain the kernel and they don't just blindly let every bit of code in. Most things go through review and go into the kernel only if Linus doesn't castrate the submitter.
TSYNC is now a current feature of the kernel. Where it came from is entirely irrelevant.
Also given the market share of Chrome on Linux in the wider scheme of the internet I think they may have only shot off the tip of one toenail. The foot will be fine.
Re: (Score:2)
My concern is that Debian, due to the lack of any long-term supported release of Chromium, will be forced to constantly update Chromium to the latest upstream version in their stable distribution.
They already do this. Just look at the changelog.
It'll get backported (Score:3, Informative)
Somethings not right (Score:2)
I'm on Debian 7 Wheezy, running Google Chrome 40.something
Is that supposed to not work?
Re: (Score:3)
crap article. (Score:3)
slashdot needs peer review, or something.
I'm running Chrome 41 on CentOS 6 -- that has kernel 2.6.32. I followed the link and one of the complaints was that Chrome remote desktop could not be installed. So I installed it. Works fine. No problems here.
Linux 3.17 clearly is not the minimum requirement.
(yes, it takes a shim to get Chrome to work on CentOS. It is a pain. see chrome.richardlloyd.org.uk -- he figured out how to make it work, and it works well.)
Wow. The linked thread... (Score:2)
is the reason why you should not let constructive users interact with ignorant technical guys.
What is so hard about actually believing to a user that if he repots something, it may be important to him (in this case chromium/flash), for reasosn which you or he may or not like, but thich are probably there.
If you dont like something, act non-constructive and get ideological.
hostile replies? (Score:3)
Hello, Julien Tinnes from google says that next releases of chromium will drops support for kernels without TSYNC. Ubuntu 14.10 already has been patched. Can I to expect that debian 8/jessie will have support for TSYNC?
Sounds like another good reason to not use Google spyware.
Google Chrome for Linux is the only possibility to use latest version of Adobe flash player for Linux as far as I know.
another good reason not to use it.
I read that as more snarky than hostile.
No loss; Chromium is my "last resort" browser (Score:3)
I even try Konqueror before I resort to Chromium.
Re:It's not even all of T'SYNC (Score:5, Funny)
Re:So much for Debian 8, then... (Score:5, Insightful)
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?
Re: (Score:3, Insightful)
Because it's yet another reason not to use them.
Re:So much for Debian 8, then... (Score:4, Insightful)
To each his own.
However, for folks who want their OS to actually pay attention to their needs, it's yet another nail in Debian's coffin.
Re:So much for Debian 8, then... (Score:4, Insightful)
That doesn't make sense. TSYNC is a security-enhancing feature.
Chrome uses seccomp-bpf for Sandboxing.... that is isolating certain threads from the system.
TSYNC facilitates software correctness with regards to the security. Without TSYNC, there is a greater likelihood of problems in the application leading to system compromise.
So I'm quite satisfied by Google's choice to refuse to run their browser on kernels that don't support current security features.
Firefox, Konqueror, Midori, Epihani, Opera, Arora, etc, should do the same.
Of course, they will have to implement multi-threaded Sandboxing functionality first.
Re:So much for Debian 8, then... (Score:4, Insightful)
I'm instead amazed by Google's arrogance in stating that RHEL 6 is "too old" for Google Chrome. It's been that way since at least last summer, so my RHEL teaching cluster and workstations just don't have chrome installed.
Actually, that's not quite true - one user manged to get Chrome working, but it regularly consumes all system resources and crashes the PC. Result.
All in all, I'm happy to do without Chrome on RHEL 6. Will I try to get it working when I roll out RHEL 7 this summer? Possibly, but moves like this make me wonder if Google's a company whose products I want to install at all. Firefox ESR may have its faults, but it basically works, and I can trust it'll stay working.
Re: (Score:3)
Perhaps I read it after you did, but *one* maintainer said he wouldn't support it, and called it spyware. (I don't know whether it is or not.) Another said that if it turns out to be needed and someone submits a "quality patch" then he would submit it. (He also said that if Chromium needed it, he would revert the patch that made it a requirement, but that Chrome was a binary that he [and implicitly Debian] had no control over.)
Re: (Score:2)
How about us people who used to think Debian was the very best Linux server system in existence, and who evangelized its use and put it in businesses and donated to SPI. But now we shun it as garbage, and actively remove it from our company's servers? Do you think that makes the Debian project happy?
Re:So much for Debian 8, then... (Score:4, Interesting)
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.
Re: (Score:3)
Moved on to....
Re: (Score:3, Informative)
The issue not google chrome, but SystemD bloatfest
Re: (Score:3, Funny)
Not referring to chrome issue, rather that giant greasy dump by Poettering into the open source pool known as SystemD
Re: (Score:3)
That's your prerogative, but keep in mind you're throwing a tantrum over a issue that does not affect the server market. No one in their right mind install a GUI on a Linux server, so again, not a issue for the server market.
Well, I can appreciate the reasons for this argument, but I also routinely do the opposite: I have many servers installed on my own "workstation" machines, which of course came with GUIs.
Of course, by "server" you were presumably referring to hardware, while for many of us software types, a "servers" is a piece of software that can run wherever we're able to compile it. So technically, we don't install GUIs on our servers; we install GUIs and other servers on our machines. They're really independent ch
Debian 8 was already a lost cause. (Score:5, Interesting)
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.
Re: (Score:2)
Friday was yesterday, Mr. Troll.
Re:Debian 8 was already a lost cause. (Score:5, Informative)
No systemd is not production ready. I've Debian testing systems in vm, and find systemd is buggy garbage.
Re: (Score:3)
Re:Debian 8 was already a lost cause. (Score:4, Interesting)
Of course, you ignore the multitude of technical arguments against it, centering on its monolithic nature and its propensity to devour everything in its path.
I don't have a lot of strong feelings about systemd, but it does strike me as fundamentally failing to understand Unix.
Re: (Score:2)
I haven't even looked to see why Chromium needs to make a kernel call that no other browser needs to make. But - I'm rather skeptical of TSYNC before I even look at it. TFS already suggests that it might be spyware. Glad I no longer run Chromium - SRWare Iron is the same as Chromium, but stripped of all the intrusive bullshit.
http://www.srware.net/en/softw... [srware.net]
Re:So much for Debian 8, then... (Score:5, Informative)
"TSYNC is a new sandboxing flag for seccomp that was recently added to the Linux kernel." -- from the description of the change to Chromium [chromium.org]
Sounds like more browsers should be using it.
Re:So much for Debian 8, then... (Score:5, Informative)
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... [kernel.org]
Re:So much for Debian 8, then... (Score:5, Informative)
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?
Re: (Score:3)
Ah looks like Ubuntu fixed it, things change I guess :-)
Re: (Score:2)
Your browser, right or wrong. Doesn't matter that the Chrome people are being ridiculously brain-damaged here, you've decided that the OS people are always wrong in any conflict.
Re: (Score:3)
No, not at all. In this case, though, it's not going in because of the animosity of one developer to all things Google. He didn't even bother to see what the change was about before shooting it down in flames.
The OS people are quite often right. Not this time, though.
Re: (Score:2)
"1) they derive directly from Ubuntu, which pays better attention to users,"
Seriously? WTF was Unity? I dumped Ubuntu as soon as they started tooting Unity's horn, and the wife dumped Ubuntu when her version with Mate desktop lost support. Pays attention to it's users? What users are those, exactly? The users who migrated from Windows, and wish to continue along the same path that Microsoft is going?
Nope, you don't get away with that one. You may state that Ubuntu satisfies all your wants and needs in
Re: (Score:2)
Better attention to its users than Debian is a low bar to clear. I'll agree that Ubuntu has its own problems in that area.
Re: (Score:2)
No, you're still not making an accurate representation.
DEBIAN'S USERS are groups such as Ubuntu, Mint (which uses both Ubuntu and Debian on different distros) Sparky, I think CrunchBang - that is, subordinate distros use Debian.
At this point in time, Sparky is paying attention to what I want, and supplying what I want in a working environment, all powered by the latest Liquorix kernel. I've seldom installed and/or assembled a desktop directly from Debian. However, Mint's LMDE had my attention for quite so
Re:So much for Debian 8, then... (Score:5, Insightful)
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.
Re: (Score:2)
You say that as though it's a bad thing.
Re: (Score:2)
Re: (Score:2)
Chrome is non-free so most distributions don't distribute it to begin with.
Re:Mailing list sounds like a bunch of Whiners.... (Score:5, Insightful)
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.
Re: (Score:3)
Does it, though? I've seen loads of claims of this behaviour, but usually it's just some muppet complaining about malware protection or getting confused about something.
Chrome's entire existence is to provide a good experience using Google's websites, some which people pay for (and so are not "the product", as the trite saying goes), and some which are ad supported.
You might want to slow down on the idiot-calling - you might end up being called one yourself.
Re: (Score:2)
no, the real LTS kernel does not get new hardwaresupport. you confuse it with the hardware enablement stack of ubuntu.
Re: (Score:2)
Re: (Score:2)
Chrome is non-free proprietary software. They have never included it in Debian.
Re: (Score:2)
The guy that said "Sounds like another good reason to not use Google spyware" does not have a Debian email address.
You mean that guy [debian.org]?