"I seriously consider the good faith of an such upstream which does these kinds of things"
"But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or forcibly cooperate with NSA and friends)."
"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."
"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."
Really if you condone this attitude then I can only say...well I won't say it but it isn't nice. Not only that, everyone seemingly ignores the: "Note that the binary blob is executed throught native client, which is not enabled by default" part.
You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.
The tone was inflammatory but the sentiment is valid. Quoting:
Since no one really know which binaries have been downloaded there and what they actually do, and since it cannot be excluded that it was actually executed, such systems are basically to be considered compromised
A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident.
Many people are used to it because of all the training received by the "Java Auto Update", "Google Update Helper" and similar software receiving blank permission to monitor, download and execute closed source software with the same permission as the logged in user.
Despite of that a person that goes to the lengths of using Debian (instead of Ubuntu) and Chromium instead of Chrome certainly expects more from their sources than to allow this kind of behaviour.
It is a security incident and should be treated as one both by Debian and by the community in general.
"A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident."
Whereas source code being downloaded, compiled and run is not? Or a script being downloaded and run?
The source code being downloaded, compiled and run or a script being download and run would be a as much a security incident as what happened.
In this context (Chromium on Debian) having a closed source binary downloaded and executed is an additional problem to the security incident and that's the reason it is mentioned in the statement. There are two problems conflated in the same sentence:
1. A binary was downloaded and executed without explicit user intervention or consent.
2. A closed source binary was downloaded and executed by a primarily free and open source software in a free and open source distribution without explicit user intervention or consent.
So, answering the questions, having the source available would not make it ok but being closed source in this context is a problem on its own.
Yes. If opening a webpage downloaded a script that permanently altered the browser adding or removing functionality without explicit user intervention or consent it would be a security incident. There is even a class of scripts that warrants a special name because of this exactly behaviour: malware.
Considering the more general case of scripts being downloaded and executed in the browser (javascript, for instance) the more apt analogy would be one being downloaded and executed in a system with NoScript installed.
Just like NoScript is a tool that gives its users the power to decide on a case by case basis which scripts are executed by the browser, Debian is a tool that gives its users the power to decide on a case by case basis which closed source binaries are executed by their system.
Preventing this choice in this context is a security incident.
I think it's totally reasonable, from the Debian mindset.
Debian is an open-source zero-binary-blob distribution. You have to deliberately choose to install binary blobs, such as driver firmware etc.
It is the dismissive response which is not appropriate. The responder asserts that the blob is safe and trustworthy, how would anybody know?.
This guy is actually perfectly right. Google doesn't do thing like that by accident. I'm glad there are some sharp guys around to disclose such potentially malicious behavior.
Do what by accident? Of course the intent was to include the blob. If Debian wants to get rid of it it should patch Chromium or request it to be made configurable (which is what happened).
But you do understand that Chromium is supposed to be open source, right?
So, if the intent was to include a binary, closed source blob into an open source project, that could be called malicious.
No, he means Chromium (like Android) in practice are read-only, hostile projects that respond only to Google's needs.
Yes, you are free to create a fork.
In reality, it's nearly impossible to keep up with Google's development pace and their behavior of dumping huge changesets and lack of documentation and communication wears everyone out. If you have some exposure to biology/ecology you'll recognize the behavior as very effective at killing off diversity in ecosystems. It's like trying to co-exist on a lake with someone that keeps deliberately causing giant algal blooms.
> No, he means Chromium (like Android) in practice are read-only, hostile projects that respond only to Google's needs.
Huh? You've obviously never involved yourself in Chromium development. It's easy to get started and to stay up to date. As with all massive projects it takes work to do so, but no more so than any of the other open source browsers.
Unlike Android, Chromium is mostly developed in the open. As someone who has contributed to both projects, I wouldn't say Chromium is any less welcoming to contributors than Firefox. Mozilla is a lot better at presenting themselves in a positive light. Firefox even has similar automated downloaded of binary blobs like the EME plugin.
>As someone who has contributed to both projects, I wouldn't say Chromium is any less welcoming to contributors than Firefox.
You're far more likely to have hidden discussions about features or get patches obsolete due to code drops out of the blue when trying to upstream to Chromium.
>Firefox even has similar automated downloaded of binary blobs like the EME plugin.
Mozilla's EME stuff was widely discussed, announced in advance, and coordinated with distros.
Even if malice instead of incompetence is involved, it goes pretty far to call Chromium a "rootkit-downloader" just because it downloads a binary blob.
It could theoretically be a rootkit, but without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.
> without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.
That's a pretty flawed analogy. If you're going to examine it from a criminal act point of view, let's really look at it that way. If installing a rootkit is equivalent to premeditated murder, then the murderer must have motive, means, and opportunity. Let's take Sony as a good example of a company guilty of installing a rootkit. Motive: Prevent unauthorized copying of their music CDs. Means: Rootkit is embedded in the audio CD and uses Windows' Autoplay feature to install itself. Opportunity: They didn't disclose this rootkit so anyone who bought a Sony audio CD during that era was vulnerable.
Now, let's look at what we know about this Chromium binary blob silent install (note I'm not calling it a rootkit, as I agree with you that's taking it a bit far, but it would theoretically be possible to install one via the same method). Motive: Google wants to put the same always-listening "feature" on Chromium installs as well as plain old Chrome. Means: Google writes and publishes the Chromium source code. Opportunity: Just guessing here, but Google releases this change without announcing it (otherwise why didn't the Debian packagers see it right away?).
Now, once again I'm in agreement with you that calling this a rootkit downloader is a bit much. But what if it had actually been a rootkit, inserted by Google either intentionally (I don't trust them, but honestly why would they do something that nefarious?), or without their knowledge or consent (which would mean they are compromised by an outside actor). That is why this is such a big deal, and kudos to the Debian team for finding it.
It also bothers me that this binary blob, while not actually a rootkit, did have the ability to listen to the computer's microphone 24/7 (yes, that is a "feature" as it is part of Google Now), and can't be audited because there is no publicly available source code. That's quite a security hole; I recall discussing all kinds of financial and personal matters with my wife right in front of our computers. Thankfully they are both desktop machines without built in microphones, but many people these days use laptops as their main computer.
To sum up, I don't like it and I think it's a shitty thing for Google to do. Whether it was intended to be a silent install instead of public knowledge, or just a major gaffe, remains to be seen.
The sandbox binary uses setuid root if user namespaces aren't available, but that's a necessity for making the empty chroot and process/network namespaces used to sandbox tabs. The layer-2 sandboxing code (seccomp-bpf) doesn't require anything like that, but they're meant to be complementary (although both are strict enough that they could act as a meaningful sandbox alone).
>this is like calling someone a murderer because he went to the same high school as a murderer //
I'd say a closer analogy would be because he had the same blood splatter pattern on his clothes as a murderer. But neither is a useful analogy they're just biased by our perspective on Google.
Think about these peoples starting point. They want a complete OS and application set built from source that is completely auditable.
This is direct circumvention of that.
Additionally, you can never prove you have removed all of your security flaws. The best you can do is search harder to become more confident that none exist. There is no way to prove that a privilege escalation flaw does not exists. Now arbitrary code is run against you wishes and without your permission.
No one can prove it didn't run a privilege escalation attack. If you think your digital security is of paramount importance you must assume you have been compromised and take steps to remedy this potential issue.
It is not that google is guilty, it is that moments before this happened security was provable and now it is not.
I think you are underestimating how much stuff you can actually prove. There's an entire field doing software verification which deals which formalizing aspects of the execution environment and proving absence of certain properties, i.e. classes of bugs, in a system. Sure, your proofs might rely on some "assumptions", but testing, a mere search for the bugs, is surely not the only way to ensure correctness.
Its not about what I am thinking. I never said anything about my thoughts on it. Perhaps I think computer security can be improved with liberal applications of butter and jelly or something equally ridiculous.
The people in question think it is an issue. They do this because of their starting point.
Whether we agree or not is not really relevant. Advising people to not read a bug report because one of the comments in the discussion associated with the report doesn't appeal to you is... strange, to say the least.
How do you manage any kind of discussion format if opinions (however wrong they may be) you don't like make you leave the discussion entirely?
On the contrary, sometimes ignoring the discussion is the only way to stay sane and make progress because there are an infinite number of people with "opinions".
In this case the original report is informative, what comes after (up to 2 posts now) probably isn't going to be.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51
Downvotes? So you agree with this?
"I seriously consider the good faith of an such upstream which does these kinds of things"
"But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or forcibly cooperate with NSA and friends)."
"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."
"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."
Really if you condone this attitude then I can only say...well I won't say it but it isn't nice. Not only that, everyone seemingly ignores the: "Note that the binary blob is executed throught native client, which is not enabled by default" part.
You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.