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: 2, Insightful) by Anonymous Coward on Tuesday November 21 2017, @07:40AM (4 children)
In my experience, "security people" tend to be mono-focused to the point that it's a little scary. They frequently want security at the expense of everything else, and in many cases it is hard to tell precisely what or who they are actually securing.
Consider precisely what being "secure" requires you to do these days. It requires you to download and install every update, preferably automatically. This means that the manufacturer gets indefinite control of your machine, the ability to install who knows what, including spyware (hi, Microsoft) and drivers intended to vandalize "unauthorized" equipment (FTDI, here's lookin' at you!). It removes the ability to have choice in your OS, which further consolidates the power in the manufacturers, and arguably the government, over what you can do with computer devices. Changing specific aspects of how the kernel functions like this that basically have the kernel commit suicide can fall into this category quite nicely.
With things like Windows 10 S being claimed "secure" despite clearly putting Microsoft in control of what software it lets you use and ultimately how you can use your system, changes to the firmware Intel is pushing, and many other factors, ultimately it appears that security is indeed an important goal. Specifically, securing the machine against you, the nominal owner, in favor of control by the manufacturer. This goes way, way beyond the argument that you don't control closed-source software. This is a fundamental change in the way that things are done, and at your expense, in the name of "security," but not for your security.
Be somewhat skeptical of security people, folks. A great many are very, very good. Others are mediocre but well-intentioned, bleating out the "update everything" mantra without even warning of the caveats. They actually want to help, but they are just doing what they are told, which is very short-sighted and does not spread understanding as to why these things may be bad. But some are blinded by their own zeal, and frequently leave a mess when they try to staple things shut, unaware of (or indifferent to) the problems they cause trying to secure the system. And unfortunately, some there are some who do not have benevolent intentions, and many companies are more interested in their own security far above the personal rights of their customers.
(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?
(Score: 1, Insightful) by Anonymous Coward on Tuesday November 21 2017, @05:27PM
The fundamental problem is that "security" (of some object) almost always comes at the expense of "availability" of that same object. Here "security" is a measure of how difficult unauthorized use of the object is, and "availability" is how easy authorized use is. The value of the object being protected has to be considered to find a good tradeoff on these axes.
For example, suppose I have a snow shovel which I use to clear snow but I don't like my neighbours to use it.
At one end of the spectrum, I could leave my snow shovel leaning against the wall next to the path I need to clear. This is very high availability: I just pick up the shovel and start shoveling. But very low security: anyone else can do that too, taking my shovel and using it for themselves.
At the other end of the spectrum, I could leave my shovel locked in a vault deep underground in another part of the country, with armed guards and the like. This is very high security, nobody will take my shovel. But very low availability: using the shovel now requires planning in advance and it is probably not possible to retrieve it on the days it is most needed. And if I misplace the key to the vault, the shovel is lost forever anyway.
Most people quite reasonably value availability more than they value security, most of the time, because the value of securing things is usually low compared to the cost of losing access to them.
(Score: 2) by urza9814 on Tuesday November 21 2017, @07:16PM (1 child)
I think you seem to be taking everyone who says to do something "for security" and assuming they're talking about THE SAME security. There's no single security community; it's all about who's writing each "expert's" paycheck.
Any discussion about security needs to start with a focus on what you're securing and who you're securing it from. Trying to pull in every possible form of security all at once results in pretty immediate contradictions. For example, enable automatic updates so you get security patches immediately, reducing the amount of time your system might be vulnerable...but also disable automatic updates because you don't know what's in those patches, they may contain new vulnerabilities, and the update servers or your connection to them could be compromised too. If you're a Microsoft employee trying to protect against script kiddies, yeah, turn on those updates from the probably local update server. But if you're a dissident trying to defend against attacks from your own government, you might be better off skipping those updates. Or reviewing the source code if possible. Security does not exist as an absolute state you should move towards; it starts with a threat model and advances from there. Different people have (and indeed *should* have) different threat models and therefore different ideas about what is or is not secure.
So of course corporate security folks just tell you to buy their latest and greatest -- they're representing the company, so attacks due to the company's negligence or malice aren't allowed to be part of their threat model (at least not in what they present to the public)...they're more going to be focused on pirates and script kiddies, in which case "run the latest version!" is pretty much the best advice they can give.
Of course, some are just plain incompetent too. I'm not sure what kind of security would be *gained* by the issue mentioned in TFA, although I'm not sure I 100% understand the details either. Could just be job security :) Or it could be a matter of training...maybe Google is training these guys to secure proprietary software, so they get used to hacks of adding layers in front of a program they can't change. Which may be valid in some environments, but not so much in the Linux kernel.
(Score: 2) by DECbot on Wednesday November 22 2017, @12:01AM
I comprehend their threat model as "there are undisclosed bugs in the kernel that malicious apps in the play store can use to gain privileged access to the Android kernel. We need the kernel to panic when a bug is utilized to reduce our liability and give us time to patch the bug." While Linus's stance is "you should focus on reducing bugs, not increasing code count by creating hoops for the kernel to jump through and increasing the likelihood of kernel panics. Only morons want to make the kernel panic instead of patching bugs."
To give a bad analogy, a home has a thermostat that produces undesired operation when subjected to cold drafts. The Pixel team suggests implementing a home security system that will report open windows and doors to the police when it suspects a draft and puts the house in lockdown in which nobody can use the house until it is rebooted. Linus says that's stupid and they should instead invest in a caulk gun and some better insulated windows and doors to prevent the drafts from coming in. However, it is summer so you don't know if you have any cold drafts that disrupt your thermostat when winter comes. But I only have a layman's understanding and thus could be missing something.
cats~$ sudo chown -R us /home/base