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