FS#41463 - [linux] enable CONFIG_RANDOMIZE_BASE

Attached to Project: Arch Linux
Opened by Daniel Micay (thestinger) - Monday, 04 August 2014, 17:49 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 22 November 2016, 07:34 GMT
Task Type Feature Request
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

As of 3.16, it's now possible to enable CONFIG_RANDOMIZE_BASE without disabling support for hibernation. It's still incompatible with hibernation, so it will be off by default and must be turned on by passing `kaslr` on the kernel line. This isn't a big deal, because user intervention is required anyway to enable dmesg_restrict and kptr_restrict.

Note that while this is intended to become a somewhat useful exploit mitigation in the future, there are known address leaks in the vanilla kernel even with dmesg_restrict / kptr_restrict enabled. It's likely going to take some time to convince upstream maintainers to incorporate the necessary changes that are currently part of grsecurity's HIDESYM feature. Information leaks are also discovered quite frequently. It would still be nice to have the feature available for testing, even in this early state.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 22 November 2016, 07:34 GMT
Reason for closing:  Won't implement
Comment by Tobias Powalowski (tpowa) - Wednesday, 13 August 2014, 07:29 GMT
I'll not add it until there is really a need by a wide user range.
Comment by AnAkkk (AnAkkk) - Friday, 26 August 2016, 13:18 GMT
  • Field changed: Percent Complete (100% → 0%)
Can we reconsider this? This improves security.
Comment by trendkiller (trendkiller) - Sunday, 23 October 2016, 16:53 GMT
Any specific reason why this wasn't implemented?
I think there is a need for good security among all users.
Comment by Jan Alexander Steffens (heftig) - Saturday, 19 November 2016, 16:33 GMT
The resulting kernel is 50% larger. Most users will have to pay this cost without any benefit, since ASLR still needs to be enabled manually (and prevents hibernation).

Personally I don't care much about kernel size, but do we really want this?
Comment by Dave Reisner (falconindy) - Saturday, 19 November 2016, 16:57 GMT
pax/grsec seem to think ill of KASLR: https://forums.grsecurity.net/viewtopic.php?f=7&t=3367
Comment by Tobias Powalowski (tpowa) - Saturday, 19 November 2016, 20:59 GMT
Seems it has more downsides than it really helps, will remove it on 4.8.10 again. And close with won't implement.

Loading...