SoylentNews is people
SoylentNews
Linux overlord Linus Torvalds has offered some very choice words about different approaches security, during a discussion about whitelisting features proposed for version 4.15 of the Linux kernel. Torvalds' ire was directed at open software aficionado and member of Google's Pixel security team Kees Cook, who he has previously accused of idiocy. Cook earned this round of shoutiness after he posted a request to "Please pull these hardened usercopy changes for v4.15-rc1."
[...] Torvalds has long been unafraid to express himself in whatever language he chooses on the kernel and has earned criticism for allowing it to become a toxic workplace. He's shrugged off those accusations with an argument that his strong language is not personal, as he is defending Linux rather than criticising individuals. On this occasion his strong language is directed at a team and Cook's approach to security, rather than directly at Cook himself. It's still a nasty lot of language to have directed at anyone.
Some 'security people are f*cking morons' says Linus Torvalds
[Reference]: [GIT PULL] usercopy whitelisting for v4.15-rc1
[Linus' Response]: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
(Score: 5, Interesting) by meustrus on Tuesday November 21 2017, @03:52PM
Getting into our current situation does not require security to be aimed at securing machines against their owners. There is a clear path to uncontrollable security policies that went something like this:
1. Start with a security model that expects users to understand the implications of running executable code
2. Break your security model with features like auto-executing code when a CD is inserted, sharing multimedia screensavers that the user is not likely to realize are actually executable code, and requiring full system access to accomplish common user-space tasks like installing a program for one user or running a web browser
3. Realize that users are executing code they don't trust because of #2
4. Scramble to create a protected execution mode for untrusted code and try to run everything possible in that execution mode
5. Realize that #4 is impossible and the best we can do is to plug holes in your security model as soon as they are discovered
6. Realize that because #5 leaves out-of-date systems at risk of already-fixed vulnerabilities and infected systems can spread their infection like a virus, the safety of everyone now requires that all users keep their software immediately up to date
The root problem is #1. However, appropriate user training could have mitigated this. Unfortunately, #2 trained users everywhere to run any potentially useful executable code without considering how much they really trust the source. Now we're in a fundamentally untenable situation where the way everybody uses computers is incompatible with the basic security model.
That solving #6 leads to Microsoft needing elevated access to every computer running Windows is just a natural consequence of this progression. Of course they're going to abuse this elevated access. I seriously doubt however that they were smart enough to set this chain of events in motion for that very purpose.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?