New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos: add a "hardened" profile #24680
Conversation
The idea is to provide a convenient way to enable most vanilla hardening features in one go. The hardened profile, then, will serve as a place for features that enhance security but cannot be enabled for all deployments because they interfere with legitimate use cases (e.g., using ptrace to debug problems in an already running process).
Any reason you're not including the grsecurity kernel in here? |
boot.kernel.sysctl."kernel.yama.ptrace_scope" = mkOverride 500 1; | ||
|
||
# Prevent replacing the running kernel image w/o reboot | ||
boot.kernel.sysctl."kernel.kexec_load_disabled" = mkDefault true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious what is the reasoning behind this setting? Loading new kernel modules is still allowed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to ensure the integrity of the kernel run-time; I had originally implemented module loading prevention here, too, but thought it more prudent to do that in a separate PR because it requires some more logic to really work. If/when the kernel loading stuff has been accepted, it'll be enabled here as well.
@copumpkin for strategic reasons, I've kept this as lightweight as possible. Also, most of these are superceded by grsec (one possible extension is to make it at least grsec aware; possibly enable grsec by default, with the current stuff as fallback). |
@joachifm curious how you'd make it grsec-aware. I'm tempted to enable both this and grsecurity in some scenarios, but am unsure if things will get weird. |
@copumpkin what I had in mind was to simply condition on |
Fair enough! |
Motivation for this change
Something like this has been brought up in relation to yama; since nobody else has proposed anything concrete (i.e., with implementation), I thought I might as well do so.
The idea is to provide a convenient way to enable most vanilla hardening features in one go. The hardened profile, then, will serve as a place for features that enhance security but cannot be enabled for all deployments because they interfere with legitimate use cases (e.g., using ptrace to debug problems in an already running process).