Why do I keep seeing Heartbleed and Shellshock mentioned in articles specifically about Linux security? Those two vulnerabilities had nothing to do with Linux.
Software using OpenSSL or bash on any platform were vulnerable. That includes Macs and Windows.
Linux is extremely popular for servers and embedded systems where OpenSSL and bash are common but bringing them up every time "security + Linux" are discussed is a bit like talking about tires that blow out whenever the topic of logistics comes up.
So by that logic, it is unfair to criticise flash and or Java as Windows security issues?
It seems like Linux people want to shift the definition of "Linux" between only the kernel and the entire OS when it is convenient. In this case we're shifting down the definition to "kernel only" so we can avoid talking about Linux (the OS's) potential security issues.
Heartbleed and Shellshock are Linux (OS) issues. Just because that same software may ship on BSD and OS X is entirely irrelevant. Linux was still by far the largest target (just like Windows is the largest target of cross-platform Java vulnerabilities).
Linux as a kernel is pretty freaking secure. Linux as an OS has a lot of issues, and many (most?) popular distributions are a large part of why (e.g. SELinux is often disabled by default and a lot of packages are incompatible, a lot of services run as root by default, a lot of packages are installed by default (not the minimum), etc).
> So by that logic, it is unfair to criticise flash and or Java as Windows security issues?
Uh, yes. They are not Windows security issues.
> Heartbleed and Shellshock are Linux (OS) issues.
No they were not. Run OpenSSL on Windows and you were just as vulnerable to Heartbleed, same as if you ran bash as a CGI service on Windows, or OSX or BSD or VMS or ...
> shift the definition of "Linux" between only the kernel and the entire OS when it is convenient.
No they don't, Linux the OS makes sense in some circumstances, not in others, this is one of those times where it doesn't since we're talking specifically about Linus' work.
> Why do I keep seeing Heartbleed and Shellshock mentioned in articles specifically about Linux security?
Because they're big, popular, well known names that effect software that typically runs on Linux systems so everyone goes "mm yep, that was a big Linux issue.'
The Linux kernel has issues, but you're not making your case that Linus doesn't take things seriously when your examples have nothing to do with Linus' work.
>Most of the security issues we've had in the kernel have been just completely stupid bugs...
Wouldn't that be an argument to be more stringent in reviewing and auditing the kernel code? I don't know to which extend they already do audits, but if you find a bug of a certain type, maybe consider combing the tree for other instances of that type of bug. I believe that's the approach OpenBSD has taken.
My very first mentor responded to me calling something "just a stupid bug" by saying "Almost all bugs are stupid." His point was that even the most talented programmers will make stupid mistakes and stupid bugs are capable of passing through large levels of code review.
Things like inverting the logic in one case of a complex conditional, or copy paste bugs like:
z1 = x1 + y1;
z2 = x2 + y2;
z3 = x3 + y1;
Are very hard to see. We have lint tools to catch a lot of them (e.g. a single '=' in a conditional), but at some point the tool lacks sufficient semantic understanding to catch everything.
IMO it's scary to hear Linus say that "security is just stupid bugs" and that he doesn't think about containers much (container/namespace security and functionality is a big and quickly emerging part of the kernel security landscape). Call it a lack of vision or whatever, but I think he should be doing more to architect for security and to recruit, place and reward talented people into security lead positions in the kernel community.
Which implementation of containers are a "quickly emerging part of the kernel security landscape"? Im seriously asking because cgroups and jails have been around for a very long time and, unlike LXC so far (for all intents and purposes, given that Docker is the most popular implementation), actually provide real security instead of dependency and devops management poorly disguised as security.
Maybe times have changed in the last year since I've used LXC containers, but when I explored them they were about as secure in practice as a paper bag is waterproof.
Windows is doing a lot of work using their hypervisor to secure parts of the kernel -- This talk from Blackhat 2015 has some really cool details: http://www.alex-ionescu.com/blackhat2015.pdf
Well for one, LXC isn't necessarily a "thing" in itself - it's a combination of several Linux kernel systems (one of which is cgroups) that together provide machine-like containers.
I sort of agree, but I think fundamentally Linus is right to marginalize most infosec people.
The vast majority of people in infosec can't see the forest for the trees, and do active harm to both usability/performance and to security by implementing security controls that are such impediments to getting anything done that people just go around them. A security control or system that nobody uses does nothing for security.
The basic mentality is "you secure things by blocking things and making them harder to access." No. This is wrong. You secure them by making them secure. A firewall with no open ports is not impressive. What's impressive is a system that does a lot and has many things open to the world and is secure. Security achievement should be measured not in an absolute sense of invulnerability -- as this is impractical -- but as the ratio of surface area to vulnerabilities. If you have no surface area exposed you've accomplished nothing; any system can be secured by turning it off. The more surface area you can safely expose, the more secure your system is and the more impressive an achievement it is from an infosec perspective.
There are some great minds in infosec who think this way but they are few and far between. Most infosec people just like to block stuff and make it harder to use.
I went to a security con a couple of years ago where one speaker pointed out that security recommendations come so thick and fast, that not even security professionals bother following many of them - and these are the people who both understand the issues and are motivated by them.
Yes, that's another problem: patching holes with chewing gum instead of systematic improvements. The latter involves abstract reasoning, something that seems somehow lacking in infosec.
> IMO it's scary to hear Linus say that "security is just stupid bugs"
That may have been what you heard, but it's not what Torvalds said. He said that most of the security issues in the kernel were stupid bugs, not that 'security is just stupid bugs'.
It's also a myth that Torvalds doesn't care about security - he does, it's just that he doesn't think security is a layer of importance above all other issues. It's just something else in the pot along with all the other important things that go into making a quality product. For example, OpenBSD does 'security above all else', and they make a couple of fantastic products... but their disdain (hatred?) of regular users means their brand is nowhere near as widely spread.
Similarly, the linux kernel is in everything from tiny embedded single-function appliances to the world's most powerful supercomputers - excluding the desktop space, it's the most popular kernel anywhere, and that's largely due to Torvalds' priorities and governance. Claims of 'lack of vision' are hard to swallow.
It also kind of sucks how grsec has remained out of tree for a decade. Its pretty much the most comprehensive security kernel there is, and all its features are kflags tweakable, but it remains a third party patchset despite providing a laundry list of extremely useful security features, most of which have no performance impact.
Its kind of silly that Apparmor is in tree but PAX is not.
Indeed, I never understood why they couldn't make a bit of effort and at least allow GRSec as a build option so it can be enabled by default on at least the server distro which are willing to waste 2% speed for some practical security layers...
I think he's just saying that it's hard to draw a circle around security, which is true. In the face of that, you can only proceed as you were. You can make things operate predictably (fix bugs), relative to the design, or you can revise the overall design targets.
To my mind, I see security meaning so many different things to different people (mostly politicians twisting it against the public) and those definitions are different enough that I couldn't reconcile them if I tried, so I don't bother. I just focus on my work. As long as the kernel is 1) reliable and 2) general enough to be used effectively by other projects that think they can define security more universally, the kernel is doing it's job well.
Maybe I'm just naive, but I don't really understood the security narrative of containers or kernel namespacing. If you have a zero-day for a VM, you still have to deal with the supervisor OS even if you can get out of the VM but it's not clear to me that that's the case with kernel-side isolation.
Am I missing something? I suppose you could implement a sub-kernel within the kernel, but then what's the point of using a container vs a VM?
Yes containers are much lighter weight than a VM, but for most people's workloads (read: anyone not running giant Map Reduce jobs) does it really matter?
Maybe security is not something you can just solve so easily, even for a kernel developer, it requires a lot of efforts in many many areas. I don't think it's his job, and I don't think he could have a big effect on linux security. It's up to people writing software that use the kernel to have good security practices.
We are in the mess we are today because everybody think "I don't think it's my job".
I have seen programmers much technically stronger and experienced than I am, and more passionate that I am, turning into idiots when talking security. It is as if, because perfect security is unreachable for any practical criteria, they automatically think it's not worth it to think about at all.
And it's really creepy to see someone in the league of Torvalds to express any feelings along those lines.
> We are in the mess we are today because everybody think "I don't think it's my job".
You're right, but we're in this mess because there isn't clear knowledge about security nor there is education teaching security on a software engineering side. There aren't simple standards and practices. Hacking a machine is not taught and you won't find tutorials for it, maybe because it's just plain outlawed.
Security is boring, and it's not rewarded. There is no insurance market for software security. If you compare it with real life security, there aren't that many people thinking about scenarios other than police forces, the FBI, insurances, and architects of buildings.
My opinion is that it's a very sensitive sector because government will always try to have the monopoly on security for obvious reasons. Linus is one guy, he doesn't have time to care. All he can do is have a sound kernel design, and that might be much enough. Maybe he can't deal with security like the NetBSD guys do.
I really think security has many, many aspects, and you can't blame one software part for it. Security is all about mitigation, which will always resides on the user and the project engineers.
Please don't take HN threads on unrelated flamewar tangents. It's one thing to go off topic in a curious or surprising way, but this one could only lead to sludge.
I don't really have a side in this whole business, but you seem to have brought this topic up entirely to slander someone, and I for one don't particularly appreciate the hijack.
I do understand this topic leads to emotional reactions from many people, and I get that it feels overwhelmingly necessary to express those feelings, but please reconsider using HN for this particular purpose in the future. If nothing else, realize that this ends up undercutting your own position by association to community harm.
The evidence boils down to a unnamed source that ESR trusts... unsourced hearsay. Pretty thin indeed!
I think commenter Anonymous4982 says it the best: "My advice: stick to writing about tech, ’cause you make yourself look like a fool when you write about politics." There might be more along those lines but it is pretty painful reading the comments on that post.
In current Internet usage I have never seen "Tea partier" used once in anything except a derisive way, outside of Tea Partiers calling themselves members of the Tea Party. Much how SJW call themselves SJW's. Unironically.
>In current Internet usage i have never seen SJW used once in anything except a derisive way.
The reason you see "SJW" used in such derisive ways is because many people hate SJW's. Just like many people hate Tea Partiers. The meaning hasn't been changed but the connotations have been co-opted to mean something else.
When I call someone a Tea Partier or Tea Party Member it's never a compliment but that doesn't mean I should call them something else if they identify as and call themselves a Tea Partier. Unless you have a suggestion on how to refer to the Tea Party without the words "Tea Party"?
I can either use their term `SJW` or I can use another accurate term `totalitarian cultural Marxists`.
I don't recall black people referring to themselves as "niggers" when the term was conceived. In contrast, SJW was coined by the people describing themselves unironically.
> Nigger just originates from the french term for "black"
It originates from a latin root, most likely by way of Portuguese or Spanish.
> how offensive could it possibly be!
As offensive as we agree to consider it. There's nothing intrinsically offensive about words, the public view about what's offensive and what's not is rather arbitrary. That's why a certain culture considers "nigger" offensive if used by pink skinned people, while "black" is perfectly neutral.
ESR is (in my opinion) insanely claiming that there is a conspiracy amongst women in OS to catch popular male developers in honeypots. He also claimed Linus was aware of the attempts and taking defensive measures. I kinda regret giving it attention but at the same time I wanted Linus to say it was insane to shut up all the really horrible people rallying behind ESR on it making it even more difficult for women in OS.
> You know when you see Linus piss on security so easily, you start to wonder - maybe that joke about allowing the NSA backdoor in the kernel was actually true?
Are you referring to the article you didn't read here?
Actual takeaway:
> "The only real solution to security is to admit that bugs happen," Torvalds said, "and then mitigate them by having multiple layers, so if you have a hole in one component, the next layer will catch the issue."
Perhaps, since he tends to be on the logical side of things, his version of that would be "I couldn't care less about it."
That's so obviously not what he's saying, though, but rather that it's never something you can "win" and that you just have to be rigorous in how you mitigate it.
Software using OpenSSL or bash on any platform were vulnerable. That includes Macs and Windows.
Linux is extremely popular for servers and embedded systems where OpenSSL and bash are common but bringing them up every time "security + Linux" are discussed is a bit like talking about tires that blow out whenever the topic of logistics comes up.