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.
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.