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