Slashdot Mirror
Security Problems Are Primarily Just Bugs, Linus Torvalds Says (iu.edu)
Linus Torvalds, in his signature voice: Some security people have scoffed at me when I say that security problems are primarily "just bugs." Those security people are f*cking morons. Because honestly, the kind of security person who doesn't accept that security problems are primarily just bugs, I don't want to work with. Security firm Errata Security has defended Linus's point of view.
Security by obscurity, government backdoors, etc. Those are not bugs.
#DeleteFacebook
It's true, security problems usually exploit a bug. BUT, in general, there is a systematic problem underneath the bug, which allows a bug in a program to escalate to gain access to root-level systems. So, it's not just a bug, but a bug that is built on a system that does not have security built in.
The alternative would be "features"
Linus's context is entirely in terms of the kernel. If you ignore that, you write comments that are complete non-sequiturs.
He is demonstrably wrong. True, some security problems are bugs, but there are also security problems that are bad design choices, that are misconfigurations, that are counting use of old technology (e.g. RSA 1024), that are poor use cases (nobody follows policy, because it is too complex and/or convoluted). You can't secure systems with just code reviews and patching. No way, no how.
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. You may disagree with this definition of a software bug from Wikipedia, but I think it lines up with what I consider a bug. The bad design choices you mention are merely another potential cause of a bug.
The context of Linus's statements must also be considered. He is talking about product level security (Linux kernal in this case), not enterprise scale system level security. At my company some security concerns are at the product level, such as ensuring users can only see the appropriate fields / records. Others are at the operations level, such as properly verifying the identity of a customer over the phone before relieving certain information. I agree with Linus that security problems at the product level are primarily just bugs. Security problems at the level of corporate policies are sometimes bugs, but also sometimes the result of people not following protocol. All the training in the world will never prevent employees from making mistakes, and sometimes it isn't possible to put checks and balances everywhere.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
You can word it the way you want. If it's not secure, it's not secure.
I tend to rant.
https://www.theregister.co.uk/...
I don't read your sig. Why are you reading mine?
The patch submitter agreed with him, don't know why everyone is jumping to white knight for him.
Torvalds point is that it can wait, and that it can be phased in. The proposal is a hardening scheme and there's a long history of hardening schemes breaking valid usage inadvertently. Torvalds perspective is that it can be done carefully, it's a nice to have, but it's not going to save the world and it's not so terrible for it to wait a little while to make sure it is right. The patch submitter said that he did a whitelist, then realized late that there were problems, added a fallback, but now it could be removed. Torvalds rightfully felt there was no way his test effort would be adequate to become a staple of the stable kernel as-is, and even suggested a course of adding a warning mechanism first to help get data to determine the risks of the mechanism.
The problem is that security folks have gone crazy and think only security matters, risking legitimate usage scenarios for the sake of security. Also, any attack is a reason to add more locks. It's like if I read that someone in my neighborhood got their house broken into because they left their door open, then I move. Then I read that someone else from that neighborhood had the same thing happen when they left the door open, and I install another lock on the door. Then it happens again and I construct an underground bunker. All the time it's because folks are leaving their doors open, but every time scares me into taking more and more unreasonable measures to counter the victimizations of those less careful.
XML is like violence. If it doesn't solve the problem, use more.
When we talk about security by obscurity we mean that the way of how the security is produced is obscured. Not that a certain secret, a key, has to be kept secret to use it.
PGP contains a private key, this is not what obscurity means in this context. What obscurity means is when the basic algorithm used to produce the encrypted result is not open to a public audit.
The key is secret. Not the lock. Big difference.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The context of the statement is that somebody submitted changes to the kernel and he denied the request.
Somebody wanted to add "security" code that would kill of a process, or even the whole kernel, if it detected something that might be a security concern. So with the proposed change, programs would crash without warning if this new code detected a possible security problem. Most of what it detects aren't attacks, though, they are just bugs in the software that need to be tweaked to explicitly follow security rules. The new security code should first warn about these bugs rather than crashing the system, Linus said. Quoting him:
So the hardening efforts should instead _start_ from the standpoint of
"let's warn about what looks dangerous, and maybe in a _year_ when
we've warned for a long time, and we are confident that we've actually
caught all the normal cases, _then_ we can start taking more drastic
measures".
A few years ago I spent some time studying ontology technologies. In a nutshell ontology is a branch of philosophy having to do with "being" and existence, but in an information technology context it refers to models of reality that are built around taxonomic models (e.g. statements like "security problems" are a kind of "software bug"). This has most obvious applications in object oriented class hierarchies, but taxonomic models are also a big part of database design and also implicitly arise in the design of data interchange formats.
Here's what I took away from my dive into the intersection of metaphysics and software engineering: taxonomic models are only valid within a specific domain of application. Even if you intend to model objective reality, you end up modeling just the parts you work with.
This is a perfect example. Torvalds is effectively saying while some security problems may not be bugs, but for practical purposes nearly all of them are. Clearly this is true for him, so true that he literally doesn't know how to work with people concerned with non-bug security problems. What he is saying has really more to do with what he does on a day to day basis, rather than about the overall field of security. In that field you also have to deal with issues like trust delegation, agency, physical security and and social engineering. Clearly Torvalds must know these things exist, but for him they might as well not.
People are very seldom concerned with some kind of universal model of capital T Truth; they're almost always concerned with creating models that help them get their job done. This is inevitable, and it creates problems when you try to glue data from different sources together. The unnecessary problems that arise come from people who don't accept that their useful domain-specific models don't describe all of objective reality.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Well, I certainly wouldn't want to endorse Torvalds' attitude here. But you encounter it, minus the armor of overwhelming fame, all the time when you work with multiple groups of stakeholders. As a system designer a lot of what you do when you develop system requirements is make localized concerns globally visible. But there are always people who don't see the needs of other users as important, and depending on how they're situated they can create a lot of grief.
People actually confuse "objective" and "subjective". I actually had a client once who even used those terms: we should focus on what's "objectively" important, by which he meant things that seemed obviously important to him. Things that were important to other stakeholders were "subjective" concerns. People do that a lot more than they realize, even if they don't use those terms. What's rare is having enough status to be an asshole about it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
... Linus doesn't mince words when it comes to pointing out bad software development.
As usual, he's right.
And before you object, think for a moment if it could actually be the case that he knows what he is talking about and may even be a better programmer than you. And that your should maybe listen to what he has to say.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
OpenBSD has promoted this belief for years. The description of their audit process states...
"Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a `newly discovered problem', and then it would be discovered that OpenBSD had been fixed in a previous release). In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the intermediate steps."
it is great to see that "kinder gentler Linus" has gone away and good old "kick 'em in the ass Linus" is back.
Linus' outrageous remarks serve kernel development well
Got to read Linus' comment in context of his post, otherwise it's a gross generalization where you're just arguing about semantics and opinions.
A better summarization of what Linus said is: take into account security aspects when designing a feature, so you don't rely on a kernel panic (or exceptions) when some rule is not observed.
Here is something analogous I ran into recently regarding a Java SDK that was not designed with security in mind. Java has a SealedObject to protect sensitive data while in memory - great feature, but then things got messy when it came to dealing with String instances. In Java it is considered bad practice to use String type to represent any kind of sensitive data like passwords because the String is immutable (i.e. it can be visible in the heap for quite a while before getting garbage collected, and if a heap dump is triggered you are screwed). What it boiled down to was the current SDK had signatures like the following:
setPassword(String pwd); // BAD!!!
instead of:
setPassword(char[] pwd); // better!
If the SDK was designed with setPassword(char[]) to begin with, SealedObject library usage would have been much simpler and cleaner - no silly security rules. But thanks to cluelessness of setPassword(String) in the SDK, SealedObject library design became much messier due to security rule to throw an exception whenever it encountered String instances were used to represent sensitive data.