Blacklist more kernel modules to reduce attack surface

Development
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
29

Good point, I reverted that commit.

I also agree that having a unique error for blacklisted modules would be easier to trace and have implemented your suggestion.

Will test more thoroughly soon.

1 Like
30

Merged, thank you!

31

I am not sure blacklisting CD-ROM is a good idea yet. Therefore commented out for now.

There will be a Kicksecure ISO live / installer at some point as well as the same for Whonix-Host. As implemented now, that ISO might be broken by default when booting from DVD.

poll:

There might be be a way to un-blacklist CD-ROM / DVD for ISO only.

32

Modules cdrom / sr_mod probably also required to boot a live / installer ISO inside a VM?

33

Added more kernel modules to the blacklist. Currently they are all prevented from automatically loading rather than being permanently disabled. We can then potentially begin the process of disabling them once compatibility is understood.

Perhaps simply blocking them from automatically loading for the time being would be an acceptable middle-ground until this can be investigated further?

1 Like
34

Refactor kernel module blacklisting and disabling for clarity, ease-of-use, and future-proofing.

In preparation for future planned changes.

If this PR is approved, I plan on immediately introducing many new additions to our existing module blacklisting and disabling. The splitting of the configuration is necessary to improve readability and not result in a single bewilderingly lengthy configuration file.

Splits /etc/modprobe.d/30-security-misc.conf into two distinct configuration files, one for blacklisting and one for disabling. Improved documentation of relevant files.

There are no changes to the actual functionality of the code.

1 Like
35

Merged. Thank you!

If you wish to refactor further, it would be good to avoid having a separate script per disabled module. Would be better to have 1 slightly more complex script and create symlinks using debian/security-misc.links instead.

The script would figure out it’s own name using $0 or $BASH_SOURCE. (Did not check which one works with symlinks.)

1 Like
36

This is a follow-up to the previous PR with a few more minor change that I think would be good.

Once again, there are no changes to the functionality of the code.

After this I will (hopefully) be submitting new additions for review.

That is a great idea!

I will work on that as an entirely separate PR once I am done submitting my current batch of changes.

1 Like
37

Thank you! Merged.

1 Like
38

The following are the bulk of the changes, I am still experimenting with other potential additions.

^ Standard disabling of largely legacy modules. Note a lot of these are superfluous as they link to already disabled modules. However, some of them do not so I though best just to comprehensively disable them.

^ Blacklisting uvcvideo could potentially cause breakages for some devices. So kept this as a separate PR. Additionally, for people who never intend to use webcams and etc., they can uncomment a line and disable the module entirely.

^ More Intel ME components are specifically disabled.

^ Disables Intel PMT.

2 Likes
39

Now that the framebuffer drivers have also been blacklisted for 2 years with no one complaining, show we disable them as well?

## Framebuffer Drivers:
## Known to be buggy, cause kernel panics, and are generally only used by legacy devices.
## These were all previously blacklisted.
##
## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist-framebuffer.conf?h=ubuntu/disco
##
install aty128fb /usr/bin/disabled-framebuffer-by-security-misc
install atyfb /usr/bin/disabled-framebuffer-by-security-misc
install cirrusfb /usr/bin/disabled-framebuffer-by-security-misc
install cyber2000fb /usr/bin/disabled-framebuffer-by-security-misc
install cyblafb /usr/bin/disabled-framebuffer-by-security-misc
install gx1fb /usr/bin/disabled-framebuffer-by-security-misc
install hgafb /usr/bin/disabled-framebuffer-by-security-misc
install i810fb /usr/bin/disabled-framebuffer-by-security-misc
install intelfb /usr/bin/disabled-framebuffer-by-security-misc
install kyrofb /usr/bin/disabled-framebuffer-by-security-misc
install lxfb /usr/bin/disabled-framebuffer-by-security-misc
install matroxfb_bases /usr/bin/disabled-framebuffer-by-security-misc
install neofb /usr/bin/disabled-framebuffer-by-security-misc
install nvidiafb /usr/bin/disabled-framebuffer-by-security-misc
install pm2fb /usr/bin/disabled-framebuffer-by-security-misc
install radeonfb /usr/bin/disabled-framebuffer-by-security-misc
install rivafb /usr/bin/disabled-framebuffer-by-security-misc
install s1d13xxxfb /usr/bin/disabled-framebuffer-by-security-misc
install savagefb /usr/bin/disabled-framebuffer-by-security-misc
install sisfb /usr/bin/disabled-framebuffer-by-security-misc
install sstfb /usr/bin/disabled-framebuffer-by-security-misc
install tdfxfb /usr/bin/disabled-framebuffer-by-security-misc
install tridentfb /usr/bin/disabled-framebuffer-by-security-misc
install vesafb /usr/bin/disabled-framebuffer-by-security-misc
install vfb /usr/bin/disabled-framebuffer-by-security-misc
install viafb /usr/bin/disabled-framebuffer-by-security-misc
install vt8623fb /usr/bin/disabled-framebuffer-by-security-misc
install udlfb /usr/bin/disabled-framebuffer-by-security-misc

Should we also consider disabling the following drivers which have all been replaced by newer drivers and have also been blacklisted for 2 years?

## Replaced:
## These have all been replaced by newer drivers.
## These were all previously blacklisted.
##
## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist.conf?h=ubuntu/disco
##
install asus_acpi /usr/bin/disabled-miscellaneous-by-security-misc
install bcm43xx /usr/bin/disabled-miscellaneous-by-security-misc
install de4x5 /usr/bin/disabled-miscellaneous-by-security-misc
install prism54 /usr/bin/disabled-miscellaneous-by-security-misc

Essentially this way we can treat 30_security-misc_blacklist.conf as the first step towards moving a kernel module into 30_security-misc_disable.conf.

I think since all of these have been blacklisted for two years it would make them good candidates?

EDIT: Move post from secuirty-misc to here as this is a more appropriate location.

40