3 ms·

The problem I have with this as a solution is that the environments where custom kernel modules or kernel modifications in general are being used as a layer of

The problem I have with this as a solution is that the environments where custom kernel modules or kernel modifications in general are being used as a layer of security are already largely customizing these threats out. Disabling kernel module loading, or restricting it to signed modules shuts down many of the vectors without using out of tree code. There are many security switches that are generally left off in widely distributed kernels that provide deep protection when you don't need to support everyone's project and app. For specific distributions like those listed this is fine, but those also generally aren't used in higher assurance environments either.

LinuxBender 7y ago
One alternate method is to have a startup script that loads your custom kernel module, then uses sysctl -w "kernel.modules_disabled=1" which can not be unset without a reboot.
cbsks 7y ago
> There are many security switches that are generally left off in widely distributed kernels that provide deep protection when you don't need to support everyone's project and app. Is there a place where these options are listed? Preferably with the pros/cons of enabling each option.
- inetknght 7y ago
  > Is there a place where these options are listed? Preferably with the pros/cons of enabling each option. Good place to start: building your own kernel from source. I tried that once and was quite overwhelmed with the sheer number of knobs and features that are available. While I do still want a centralized list of things to do/check for hardening a kernel, I don't think it will _ever_ be exhaustive. And some pros/cons would involve very _deeply_ complex behavior which would be difficult to determine whether or not the tradeoff is even relevant.
Hello71 7y ago
that doesn't sound like an accurate portrayal of the article at all. "Kernel Read-Only Primitive" and "Kernel Write-Only Primitive" are vague, but as far as I can tell, "SWAPGS", "BadIRET", "SysRet", and "Pop SS" are in core kernel code which cannot be configured out with Kconfig. CVE-2017-5123 is in waitid, which I believe cannot be configured out, and CVE-2017-1000112 is in TCP, which can be disabled, but is virtually never done. I don't think anything in this article talks about exploits from kernel modules. In fact, according to the article, LKRG can be trivially disabled from root by simply running "rmmod p_lkrg".

LinuxBender 7y ago

One alternate method is to have a startup script that loads your custom kernel module, then uses sysctl -w "kernel.modules_disabled=1" which can not be unset without a reboot.

cbsks 7y ago

> There are many security switches that are generally left off in widely distributed kernels that provide deep protection when you don't need to support everyone's project and app. Is there a place where these options are listed? Preferably with the pros/cons of enabling each option.

inetknght 7y ago
> Is there a place where these options are listed? Preferably with the pros/cons of enabling each option. Good place to start: building your own kernel from source. I tried that once and was quite overwhelmed with the sheer number of knobs and features that are available. While I do still want a centralized list of things to do/check for hardening a kernel, I don't think it will _ever_ be exhaustive. And some pros/cons would involve very _deeply_ complex behavior which would be difficult to determine whether or not the tradeoff is even relevant.

Hello71 7y ago

that doesn't sound like an accurate portrayal of the article at all. "Kernel Read-Only Primitive" and "Kernel Write-Only Primitive" are vague, but as far as I can tell, "SWAPGS", "BadIRET", "SysRet", and "Pop SS" are in core kernel code which cannot be configured out with Kconfig. CVE-2017-5123 is in waitid, which I believe cannot be configured out, and CVE-2017-1000112 is in TCP, which can be disabled, but is virtually never done. I don't think anything in this article talks about exploits from kernel modules. In fact, according to the article, LKRG can be trivially disabled from root by simply running "rmmod p_lkrg".