Skip to content
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: implement option to disable automatic kernel module loading #24681

Closed

Conversation

joachifm
Copy link
Contributor

@joachifm joachifm commented Apr 6, 2017

Motivation for this change

The rationale for this over simply setting the sysctl knob is to allow some legitmate kernel module loading to occur; the naive solution breaks too much to be useful.

@mention-bot
Copy link

@joachifm, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @bjornfor and @offlinehacker to be potential reviewers.


# Assume that all legitimate module loading has occurred by the time
# we're activated. NOTE: may not hold if X11 is enabled but not
# configured to run automatically.
Copy link
Member

@Mic92 Mic92 Apr 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this comment, to the description as well. It should be also mentioned that kernel module loading is disabled after configured kernel modules are loaded.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. This is still not quite fleshed out :)

@joachifm
Copy link
Contributor Author

This would be superceded by https://lkml.org/lkml/2017/4/19/1086 once and if that lands (port of grsec module hardening).

description = "Disable automatic kernel module loading";

wantedBy = [ config.systemd.defaultUnit ];
after = [ "systemd-modules-load.service" ] ++ wantedBy;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it should be ordered after systemd-udev-settle.service as well. And possibly after firewall.service since iptables will autoload required modules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had initially hoped that ordering after the default target would suffice, but it makes sense to be conservative here to make it maximally robust. I'll add the suggested ordering.

description = ''
Disable automatic kernel module loading once the system is fully
initialised. Module loading will be disabled until next reboot.
Problems caused by delayed module loading are fixed by adding the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are fixed by -> can be fixed by.

@joachifm joachifm force-pushed the disable-kernel-module-autoload branch 2 times, most recently from bec0444 to a2704c7 Compare April 29, 2017 16:56
Adds an option `security.lockKernelModules` that, when enabled, disables
kernel module loading once the system reaches its normal operating state.

The rationale for this over simply setting the sysctl knob is to allow
some legitmate kernel module loading to occur; the naive solution breaks
too much to be useful.

The benefit to the user is to help ensure the integrity of the kernel
runtime: only code loaded as part of normal system initialization will be
available in the kernel for the duration of the boot session.  This helps
prevent injection of malicious code or unexpected loading of legitimate
but normally unused modules that have exploitable bugs (e.g., DCCP use
after free CVE-2017-6074, n_hldc CVE-2017-2636, XFRM framework
CVE-2017-7184, L2TPv3 CVE-2016-10200).

From an aestethic point of view, enabling this option helps make the
configuration more "declarative".
@joachifm joachifm force-pushed the disable-kernel-module-autoload branch from a2704c7 to 510b8b0 Compare April 30, 2017 10:01
@joachifm joachifm closed this in 878ad1c Apr 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants