Linus 'Linux' Torvalds gives security developers guidance
Security
Linus Torvalds, creator of Linux, has never suffered fools gladly. In particular, he really dislikes people who make improving security in Linux more trouble than it needs to be. Most recently, in his own inestimable style, he called some security developers "f*cking morons". But, Torvalds, while often colorful, also gave direction to security programmers.
It all started when Torvalds took Google Pixel developer Kees Cook, who had submitted a pull request that could have caused Linux kernel panics, to task. Torvalds snarled, "Honestly, this is the kind of completely unacceptable 'security person' behavior that we had with the original user access hardening too, and made that much more painful than it ever should have been. IT IS NOT ACCEPTABLE when security people set magical new rules, and then make the kernel panic when those new rules are violated."
He reminded security programmers that "security problems are just bugs." And, that security hardening patches should never result "in killing processes. The only process I'm interested in is the _development_ process, where we find bugs and fix them."
His position isn't new. In 2008, Torvalds wrote, "To me, security is important. But it's no less important than everything *else* that is also important!"
Torvalds isn't the only one who sees it that way. An independent security researcher, said on the Linux Kernel Mailing List (LKML), "Some security people scoff at other security people's obsession with 'security bugs'. The security industry is largely obsessed by finding (and selling/using/patching/reporting/showcasing/stockpiling/detecting/stealing) these 'dangerous/useful' variety of bugs. And this obsession is continually fulfilled because bugs keep happening -- which is just the nature of software development -- and so this 'security bug' infatuation continues."
This is the major reason we have endless stories about the latest Android, Windows, whatever, security hole. Torvalds, for one, has long been sick of this.
It's not that security bugs aren't real nor that they're important. But, the sky is not falling nearly as often as chicken-little security companies and developers would have you believe.
Torvalds explained to Donenfeld that from where he stands, "Security-first people tend to see the big win is when the [insecure] access is _stopped_. That's the end of the story from a security standpoint."
"But," Torvalds continued, "from a developer standpoint, things _really_ just are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. So, from a developer standpoint, the end point of hardening is just the starting point, and when _you_ think you're done, we're really only getting started."
So how should security developers approach Torvalds when they submit a patch?
Well-known security and Linux developer Matthew Garrett posed that question to Torvalds on the LKML. True, Garrett observed, "Kees learned from that experience and added the default fallback in response to it. Let's reward people for learning from past problems rather than screaming at them." After all, Garrett continued, "The number of people willing to work on security stuff is limited enough for various reasons, let's try to keep hold of the ones we have!"
Torvalds admitted he had been overworked and he apologized. "Sorry for the strong words."
So what do security developers do when working on Linux kernel code? Here are Torvalds' rules for security developers:
- When adding hardening features, you as a security person should always see that hardening to be the _endpoint_, but not the immediate goal.
- When adding hardening features, the first step should *ALWAYS* be "just report it". Not killing things, not even stopping the access. Report it. Nothing else.
- "Do no harm" should be your mantra for any new hardening work.
If programmers stick to these rules, Torvalds will swear less and fewer bugs will make it into the Linux kernel.
Related Stories: