Closed cynicsketch closed 3 months ago
Hello,
Thanks for the suggestion!
"information leak" is only to root when kernel lockdown is enabled
While the unhashed kernel addresses would leak to root, I am not sure whether it matters if kernel lockdown mode is enabled or not.
A bit of history first, slub_debug=FZP
was added in https://github.com/Kicksecure/security-misc/commit/02e8888b0bc4f0dfadccbebc9e6e75849d32ba76, this was then changed be slub_debug=FZ
in https://github.com/Kicksecure/security-misc/commit/bd31b4085c853d8b182e3a13534827a695f5493a (as we upgraded Debian), I then disabled slub_debug=FZ
in https://github.com/Kicksecure/security-misc/commit/f572332108c06eb77d24e776910463e69d49acd3, then I refactored its presentation in https://github.com/Kicksecure/security-misc/commit/a33d4cd099b8cbf569ff35627eeacf3562a4371e, and finally I removed it in https://github.com/Kicksecure/security-misc/commit/48e1ac416314d2c66f3a0d5044a3c51cb6fb4093.
I think the argument rests on the significance of enabling kernel pointer hashing which requires these debugging parameters to be disabled (which is the Linux kernel default) versus the security benefits which are currently advocated by KSPP.
Recall that theses are designed to be debugging options, not security options and so if in the future more debugging functionality is added it may lead to problems. Enabling slub_debug=FZ
would require people to keep vigilant on what changes are made moving forward (or at the very least regularly checking with KSPP).
As a first step we could consider potentially reverting https://github.com/Kicksecure/security-misc/commit/48e1ac416314d2c66f3a0d5044a3c51cb6fb4093 and adding a link to this discussion.
Also see kernel documentation: https://www.kernel.org/doc/html/latest/mm/slub.html
Great history, thank you, @raja!
Yes. At very least we could add a comment.
This should be best brought up at KSPP and potentially elsewhere as well.
On a second thought, we can defer to KSPP as an authority.
Could you please send a pull request to re-enable?
If someone wishes to argue against slub_debug=FZ
, they should bring this up at KSPP or make a compelling argument elsewhere.
Also slab
vs slub
?
Also
slab
vsslub
?
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
slab_debug[=options[,slabs][;[options[,slabs]]...] [MM] ... (slub_debug legacy name also accepted for now)
https://docs.kernel.org/mm/slub.html
"Short users guide for SLUB ... Some more sophisticated uses of slab_debug: Parameters may be given to slab_debug ... "
Seems to be just semantics?
https://tails.net/contribute/design/kernel_hardening/ https://gitlab.tails.boum.org/tails/tails/-/issues/19613 https://kspp.github.io/Recommended_Settings
slub_debug is not apparently used in Kicksecure (and friends Whonix and QubesOS).
Tails and KSPP, however, do recommend using
slub_debug=FZ
, still used in Tails to this day.In summary of these sources, the consensus is that slub debugging is not generally harmful because the "information leak" is only to root when kernel lockdown is enabled, and that it therefore doesn't matter that kernel pointer hashing is disabled because root should never be compromised.
Concerns of risk of slub debugging would therefore be overstated.
Not sure about any other contraindictions, though.