Blacklist more kernel modules to reduce attack surface

Development
9

Because root access means game over if malware gained root. The attacker has way too many ways to compromise the system in persistent ways. Root should be allowed to load the module / mount any disk.

2 Likes
10

Modprobing stuff would be one of the options for a kernel exploit. Certainly not the only one but at least one options less for the attacker.

Edit: We also have apparmor which limits what a user, including root, can do.

2 Likes
11

Larger discussion. Created Untrusted Root - improve Security by Restricting Root for it.

2 Likes
12

It’s there for me in Virtualbox. Virtualbox might add CD-ROM support by default while Qubes only adds the bare minimum. If so, is there a way to disable it in the Virtualbox ovas by default?

An attacker could attempt to mount something containing the filesystem which will load the module.

Things like thunar-volman and udisks allow unprivileged mounting.

Root can just remove the file that blacklists these modules anyway.

13

Ubuntu’s default blacklisted modules: modprobe.d\debian - ubuntu/+source/kmod - [no description]

2 Likes
14

As per linux - Methods root can use to elevate itself to kernel mode - Information Security Stack Exchange, we should disable CPU MSRs.

MSRs are only exposed when the msr module is loaded so we can blacklist that module to prevent them from being abused.

1 Like
15

Does this break virt-detect?

1 Like
16

Good point but even if it does, that is only required by two features.

  • [1] power-savings-disable-in-vms
  • [2] whonixcheck warn against unsupported virtualizers

Non-essential features. [1] could be implemented in another way.

Kicksecure has both, VM and host packages:

  • kicksecure-cli-vm / kicksecure-cli
  • kicksecure-xfce-vm / kicksecure-xfce

Whonix doesn’t have that yet and it’s difficult to make the conversion for existing users. (Since this is the “top level” meta package.)

[2] might be lost but I guess that is a feature reduction we can endure.

1 Like
17

No. MSRs have nothing to do with that.

1 Like
18

I’m pretty sure they do because when i blocked access to them using libvirt it broke hypervisor detection, but @Patrick explained it’s not a big deal.

1 Like
19

No, you can even test it yourself by running systemd-detect-virt and seeing the msr module isn’t even loaded.

2 Likes
20

Good to know. Then go for it :grinning:

2 Likes
21
1 Like
22

Merged.

2 Likes
23
1 Like
24 
W: security-misc: obsolete-command-in-modprobe.d-file etc/modprobe.d/30_security-misc.conf install
N:
W: obsolete-command-in-modprobe.d-file
N:
N:   Use of 'install' and 'remove' commands in module files in
N:   /etc/modprobe.d and /etc/modules-load.d is deprecated and should be
N:   replaced with 'softdep' commands.
N:   
N:   Severity: warning
N:   
N:   Check: modprobe
N:
25

I don’t think softdep would replace security-misc use case of install msr /bin/false etc.

26
27
28

Finally, the use of /bin/false should perhaps be replaced with /bin/true.
Blacklist more kernel modules by raja-grewal · Pull Request #109 · Kicksecure/security-misc · GitHub

I prefer module load failures to produce error messages that can be investigated over silent breakage that is hard to track down what is causing it.

Could you please revert that specific commit?

Instead of /bin/false perhaps the following would be even easier to investigate?

/bin/disabled-by-security-misc

#!/bin/bash
echo "$0: ERROR: This kernel module is disabled by package security-misc by default. Most likely by configuration file /etc/modprobe.d/30_security-misc.conf | args: $@" >&2
exit 1