9 ms·

> There is a lot of drama around the fact Linux core devs don't adopt these patches by default. What is the main cause of resistance for implementing these fix

> There is a lot of drama around the fact Linux core devs don't adopt these patches by default. What is the main cause of resistance for implementing these fixes? It worries me that they haven't put forth the effort to do so yet.

dmix 12y ago
Daniel Micay who works on security with Arch Linux explains why GRSecurity hasn't been upstreamed here: http://article.gmane.org/gmane.comp.security.oss.general/15054 http://article.gmane.org/gmane.comp.security.oss.general/150... And you can see Greg K H (a linux core dev) snarky reply here: http://article.gmane.org/gmane.comp.security.oss.general/15056 http://article.gmane.org/gmane.comp.security.oss.general/150... Basically a few people have tried in the past but Linux core devs are against large patches. And if you look at old threads [1] where people have attempted to break it up into small patches the core devs have been disinterested. Just to be clear we're talking about many 2003-era exploit mitigation techniques not being adopted into the kernel. And as a side effect every year there are countless vulnerabilities that come out - for which proactive mitigations with up-to-date PoC's have existed for years. Greg KH basically said in that thread that it would need to be broken up into tons of small patches. Then each patch will have to be submitted and go through the massive politics of getting it upstreamed. This would require a full-time paid team of people doing it, since Linux foundation or similar organizations don't seem to think it's worth paying for a team of security experts themselves to do similar work hardening the kernel. Additionally, a long time ago (before grsec I believe) the person (or team) behind PaX, whose code is now a significant percentage of GRSecurity, is anonymous and the Linux core refused to accept patches from anonymous developers. Also for a more meta-discussion on how security is handled by the core devs see Spenders summary here in "KASLR: An Exercise in Cargo Cult Security" https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 [1] Spender links to old threads here where people tried breaking it up and submitting small patches: https://twitter.com/grsecurity/status/541797486479028225 https://twitter.com/grsecurity/status/541797486479028225 https://twitter.com/grsecurity/status/541797673419145217 https://twitter.com/grsecurity/status/541797673419145217 https://twitter.com/grsecurity/status/541797780482977792 https://twitter.com/grsecurity/status/541797780482977792
- mburns 12y ago
  "I'm glad to help out with this if you can point me at specific examples of things that should be changed." Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.
  - deleted 12y ago
    [deleted]
  - someengineer 12y ago
    Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.
    - dmix 12y ago
      No one in that thread is recommending the Linux devs take the monolithic GRSecurity patches flat out. If you read the originally linked thread Daniel explains why it can't be accepted this way nor does he propose it should. Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).
      - nodata 12y ago
        Maybe the grsec people should better communicate the advantage. I suggest taking each CVE and listing whether it would have been mitigated by running a grsec kernel, and compare it to something else (selinux or whatever)
        dmix 12y ago
        If there is a kernel privilege escalation then SELinux can be disabled as Spender loves to demonstrate https://www.youtube.com/watch?v=WI0FXZUsLuI https://www.youtube.com/watch?v=WI0FXZUsLuI GRSec does includes it's own MAC system as an alternative to SELinux but that is only a small part. PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers. To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.
alecco 12y ago
Linus hates security and security related projects. He is against prioritizing security bugs over normal bugs. Also he is against embargo (coordinated release). One example of many, many instances: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html
- api 12y ago
  I simultaneously agree and disagree with him. I think he's wrong because security is increasingly critical, but I agree with him because I can't stand (most of) the infosec profession. The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience. Not only does this break everything else, but it's bad for security in the long run. The typical security solution is something that makes it so hard for people to do ordinary work that they either disable it entirely (e.g. SELinux) or work around it (tunneling through aggressive firewalls, etc.) and defeat the whole purpose. I worked in a research institution once where some departments had people whose informal job description (I was told) was to "help work around security so we can get our work done." If you worked with security, they'd put up so many road blocks and say "no" to so many things that months and months could go by without a single thing being accomplished. There was a whole culture of literally conspiring to ignore and sidestep the security department. People kept doing this even after we got hacked, arguing (again explicitly) that the cost of complying with infosec was greater than the cost of the hack. Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems. I firmly believe that almost nothing can be done well without whole system thinking. You have to look at the entire context of a system, not just the one thing you're building or optimizing. Think about the system from technical details all the way up to how users will interact with it on a day to day basis. A good starting point is to look at whatever you're building and ask "how annoyed would I be if management foisted this on me?" If the answer is "very annoyed," your system has horrible UX. This isn't the only case where I simultaneously agree and disagree with Linus. Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead. As with many other "powerful" multi-paradigm languages it takes discipline to avoid over-using the language's features, and most programmers unfortunately have the opposite tendency. They over-abstract and over-engineer as if they're trying to show how clever they are.

dmix 12y ago

Daniel Micay who works on security with Arch Linux explains why GRSecurity hasn't been upstreamed here: http://article.gmane.org/gmane.comp.security.oss.general/15054 http://article.gmane.org/gmane.comp.security.oss.general/150... And you can see Greg K H (a linux core dev) snarky reply here: http://article.gmane.org/gmane.comp.security.oss.general/15056 http://article.gmane.org/gmane.comp.security.oss.general/150... Basically a few people have tried in the past but Linux core devs are against large patches. And if you look at old threads [1] where people have attempted to break it up into small patches the core devs have been disinterested. Just to be clear we're talking about many 2003-era exploit mitigation techniques not being adopted into the kernel. And as a side effect every year there are countless vulnerabilities that come out - for which proactive mitigations with up-to-date PoC's have existed for years. Greg KH basically said in that thread that it would need to be broken up into tons of small patches. Then each patch will have to be submitted and go through the massive politics of getting it upstreamed. This would require a full-time paid team of people doing it, since Linux foundation or similar organizations don't seem to think it's worth paying for a team of security experts themselves to do similar work hardening the kernel. Additionally, a long time ago (before grsec I believe) the person (or team) behind PaX, whose code is now a significant percentage of GRSecurity, is anonymous and the Linux core refused to accept patches from anonymous developers. Also for a more meta-discussion on how security is handled by the core devs see Spenders summary here in "KASLR: An Exercise in Cargo Cult Security" https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 [1] Spender links to old threads here where people tried breaking it up and submitting small patches: https://twitter.com/grsecurity/status/541797486479028225 https://twitter.com/grsecurity/status/541797486479028225 https://twitter.com/grsecurity/status/541797673419145217 https://twitter.com/grsecurity/status/541797673419145217 https://twitter.com/grsecurity/status/541797780482977792 https://twitter.com/grsecurity/status/541797780482977792

mburns 12y ago
"I'm glad to help out with this if you can point me at specific examples of things that should be changed." Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.
- deleted 12y ago
  [deleted]
- someengineer 12y ago
  Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.
  - dmix 12y ago
    No one in that thread is recommending the Linux devs take the monolithic GRSecurity patches flat out. If you read the originally linked thread Daniel explains why it can't be accepted this way nor does he propose it should. Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).
    - nodata 12y ago
      Maybe the grsec people should better communicate the advantage. I suggest taking each CVE and listing whether it would have been mitigated by running a grsec kernel, and compare it to something else (selinux or whatever)
      - dmix 12y ago
        If there is a kernel privilege escalation then SELinux can be disabled as Spender loves to demonstrate https://www.youtube.com/watch?v=WI0FXZUsLuI https://www.youtube.com/watch?v=WI0FXZUsLuI GRSec does includes it's own MAC system as an alternative to SELinux but that is only a small part. PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers. To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.

alecco 12y ago

Linus hates security and security related projects. He is against prioritizing security bugs over normal bugs. Also he is against embargo (coordinated release). One example of many, many instances: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html

api 12y ago
I simultaneously agree and disagree with him. I think he's wrong because security is increasingly critical, but I agree with him because I can't stand (most of) the infosec profession. The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience. Not only does this break everything else, but it's bad for security in the long run. The typical security solution is something that makes it so hard for people to do ordinary work that they either disable it entirely (e.g. SELinux) or work around it (tunneling through aggressive firewalls, etc.) and defeat the whole purpose. I worked in a research institution once where some departments had people whose informal job description (I was told) was to "help work around security so we can get our work done." If you worked with security, they'd put up so many road blocks and say "no" to so many things that months and months could go by without a single thing being accomplished. There was a whole culture of literally conspiring to ignore and sidestep the security department. People kept doing this even after we got hacked, arguing (again explicitly) that the cost of complying with infosec was greater than the cost of the hack. Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems. I firmly believe that almost nothing can be done well without whole system thinking. You have to look at the entire context of a system, not just the one thing you're building or optimizing. Think about the system from technical details all the way up to how users will interact with it on a day to day basis. A good starting point is to look at whatever you're building and ask "how annoyed would I be if management foisted this on me?" If the answer is "very annoyed," your system has horrible UX. This isn't the only case where I simultaneously agree and disagree with Linus. Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead. As with many other "powerful" multi-paradigm languages it takes discipline to avoid over-using the language's features, and most programmers unfortunately have the opposite tendency. They over-abstract and over-engineer as if they're trying to show how clever they are.