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.
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
https://www.theregister.co.uk/...
I don't read your sig. Why are you reading mine?
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.