1. 8
  1.  

  2. 5

    I’m completely baffled this wasn’t done years ago.

    1. 3

      This is really good to see. That Google is putting grsec-based features in Android shows the strength of the grsec/PaX design and philosophy. Those implementing exploit mitigations in today’s operating systems should take note.

      1. 2

        A perhaps unrelated question: is anyone running grsec on a GNU/Linux desktop without disabling any of the protections for their day-to-day usage? I’ve considered implementing it on several occasions, but on each occasion, I’m reminded that I’ll effectively be disabling the protections on large parts of the stack: gnome-shell, qt components, firefox… You know, the very targets most ripe for the kinds of exploits that grsec is meant to contain.

        Don’t get me wrong. grsec is an awesome project. It’s not grsec’s problem that so much software has been developed without its security model in mind. But I can’t help but feel like using grsec –in a desktop context at least– is a pointless endeavor if you still end up disabling it for large portions of your stack.

        1. 2

          Speaking specifically about Firefox, now that Firefox 47 and on support W^X compat, disabling W^X for Firefox shouldn’t be needed anymore for grsec-based systems.

          Using HardenedBSD as an example, though, we still have to disable W^X protections for Firefox on HardenedBSD because we don’t yet support TEXTRELs in our implementation. Support for TEXTRELs should be completed in the coming months, at which point, we shouldn’t have to disable W^X protections for Firefox.

          But, the vast majority of applications I use don’t need any protections disabled. zsh, git, clang, make, etc. don’t require RWX mappings.