On Fri, Mar 22, 2019 at 10:46 AM Peter Humphrey <[email protected]> wrote: > > Years ago, in the days of Yggdrasil I think, the received wisdom was that > enabling kernel module loading was a bad idea because an attacker might be > able to load malicious software directly into the kernel. No modules --> one > more attack route closed. > > What is the current thinking on this topic? I'm not trolling; I'd like to know > which way to go with a new box. >
IMO unless you're already using SELinux/etc this seems like a minor concern to focus on. You can't load kernel modules unless you're root, and if you have root then everything is wide open anyway. Now, if you're using a more hardened configuration where somebody who has root access is contained, but they might still be able to load modules, then this might be a meaningful protection. However, I suspect that most approaches to hardening that limit the capabilities of root are going to also limit the ability to load modules. In linux you need the CAP_SYS_MODULE capability to load a kernel module. I have to imagine that this is one of the first things you'd drop in any kind of hardened design since the need to load modules is very niche but very powerful. Now, if you want to make the argument that every system call is one more attack vector, then, sure, I guess this applies, but imo the odds that there is some exploit in the kernel where a process lacking CAP_SYS_MODULE could call init_module anyway seems pretty low. If you're going to be worried about this sort of vector then you should be selectively removing just about any system call that your application doesn't need, or just looking at microkernels or whatever. -- Rich
