Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
517 stars 51 forks source link

Use `slub_debug=FZ`? #253

Closed cynicsketch closed 3 months ago

cynicsketch commented 4 months ago

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.

raja-grewal commented 4 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

adrelanos commented 3 months ago

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.

adrelanos commented 3 months ago

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.

adrelanos commented 3 months ago

Also slab vs slub?

cynicsketch commented 3 months ago

Also slab vs slub?

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?

adrelanos commented 3 months ago

Done since

was merged.