Linus Torvalds Talks Linux Security at LinuxCon

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

For the same reason you see X and Vim being referred to as Linux software.

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

Yep, the discussion should've been about kexec and secureboot.

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.

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.

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.

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.

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.

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.

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