Grsecurity and Pax without mprotect() restriction

[alan.d]

Let me say that I am an impressed user of a grsecurity patched kernel, but in general I experience big trouble when enabling mprotect(). I understand that it is userland's fault that PAX constantly kills programs that were not writting with that restriction in mind, but still I have been experimenting on my Desktop machine and the whitelist grew very big, so gave up on mprotect by default, simply because often PAX spontaneously killed applications, because a new situation was faced I did not have before and I had to again expand the white list (for example firefox was suddenly killed after a few minutes of work, because some dbus call was not allowed), despite the fact firefox was already on the whitelist.
With applications like firefox, where this functionality would really make sense, already being on the whitelist I see no reason to further struggle with the whitelist and simply disable the mprotect restrictions, because it breaks almost my whole desktop by default.

Now I am wondering if disabling the mprotect() restrictions renders some of the other stuff provided by grsec useless? I guess a patched kernel without mprotect() is still better than an unpatched kernel, right? How bad is the situation really without the mprotect restrictions? Could you enlighten me a bit more? Is it really worth the trouble with whitelisting every single application that is broken? (when already dangerous applications like firefox are whitelisted?)

[strcat]

The MPROTECT feature raises the difficulty of exploitation by forcing the usage of existing code rather than injecting new code, and in some cases that might even be enough to prevent the vulnerability from resulting in remote code execution even with a lot of targeted effort. I'm not an expert on writing exploit code, so I don't know how much of barrier it is to force the usage of ROP gadgets all the way rather than allowing escalation to arbitrary shellcode via mprotect.

An application needing an exception from the MPROTECT feature isn't necessarily broken. It's usually a result of the application's design rather than something like broken position dependent assembly code. I don't find it hard to maintain a list of the necessary exceptions. You're free to start from the list I maintain for Arch if you want to avoid most of the work (note that it uses an MPROTECT exception when it could get away with EMUTRAMP in a few cases).

Firefox is weak from a security standpoint for more reasons than just dynamic code generation. The JIT compiler doesn't do any hardening or even basic layout randomization and it has no renderer sandbox. It doesn't even use PIE in the official builds. Since the browser is the biggest attack surface on most desktops, I would recommend using Chromium instead if you're at all security conscious.

[alan.d]

Thanks for the link to that list!
Normally I use chromium, but even for chromium I would have to disable mprotect.
The mprotect restriction is in my experience the biggest usability hurdle on a Desktop when you want to get non security related things done. Applications are suddenly killed by PAX which hurts your working life by big extent. I know, if you want the best security you have to live with that pain. But I am perfectly fine with everything enabled when using automatic configuration, Desktop and security as priority and disabling the mprotect setting. I think that is the optimum for usability (of course this is exactly the opposite to security), but you cannot have everything.
Now I wonder, if I break other security mechanisms by disabling that? Of course every whole can be bad in case of an exploit, because once an attacker is in, everything else is of course useless too, but is disabling mprotect that bad?