Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Tuesday November 21 2017, @05:00AM   Printer-friendly
from the yes-but-be-nice dept.

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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by urza9814 on Tuesday November 21 2017, @07:16PM (1 child)

    by urza9814 (3954) on Tuesday November 21 2017, @07:16PM (#599797) Journal

    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.

    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.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DECbot on Wednesday November 22 2017, @12:01AM

    by DECbot (832) on Wednesday November 22 2017, @12:01AM (#599974) Journal

    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