security-misc
security-misc copied to clipboard
criteria for kernel module blacklisting / disabling / Suggestions for kernel modules blacklisted in /etc/modprobe.d/30_security-misc.conf
Digital Video Broadcasting
install dvb_core /bin/true # Core module for DVB devices install dvb_usb_rtl2832u /bin/true # DVB-T USB devices with RTL2832U chipset install dvb_usb_rtl28xxu /bin/true # DVB-T USB devices with RTL28xx chipset install dvb_usb_v2 /bin/true # Newer DVB USB framework install rtl2830 /bin/true # Realtek RTL2830 DVB-T receiver install rtl2832 /bin/true # Realtek RTL2832 DVB-T receiver install rtl2832_sdr /bin/true # RTL2832-based SDR devices install rtl2838 /bin/true # Realtek RTL2838 DVB-T receiver
Point-to-Point Protocols
install ppp_async /bin/true # Point-to-Point Protocol for asynchronous connections install ppp_deflate /bin/true # Compression module for PPP install ppp_generic /bin/true # Generic PPP support install pppoe /bin/true # PPP over Ethernet install pppox /bin/true # PPP over various transports install slhc /bin/true # SLIP/PPP compression and decompression
Intel Platform Monitoring Technology Telemetry (Intel-PMT)
install pmt_class /bin/true # Platform Monitoring Telemetry (Intel) install pmt_telemetry /bin/true # Platform Monitoring Telemetry (Intel)
Network Drivers
install brcm80211 /bin/true # Very old Broadcom wireless driver install cfg80211 /bin/true # Wireless API for a very old Broadcom device install eepro100 /bin/true # Very old network driver install eth1394 /bin/true # Very old network driver install rtl8187 /bin/true # Realtek RTL8187 wireless LAN driver
Miscellaneous Drivers
install fddi /bin/true # Fiber Distributed Data Interface install floppy /bin/true install hamradio /bin/true # Amateur radio protocol install ib_ipoib /bin/true # InfiniBand over IP install joydev /bin/true # Joystick support install lp /bin/true # Printer support for parallel port install parport /bin/true # Parallel port support install tr /bin/true # Token Ring protocol install uvcvideo /bin/true # USB Video Class driver
FileSystem
install jfs /bin/true # IBM's Journaled File System install reiserfs /bin/true # ReiserFS filesystem install squashfs /bin/true # SquashFS filesystem
Blacklisted : Make this optional and can be loaded later
blacklist amdgpu blacklist b43 # Quite old Broadcom wireless driver blacklist exfat blacklist iwlwifi # Intel wireless driver blacklist mac80211 # Printer support for parallel port blacklist ntfs blacklist nvidia blacklist radeon blacklist usb_storage blacklist uinput # User-level input driver
Hello, thanks for your suggestions. Many of these seem certainly very actionable.
However. given the number of modules to be disabled, it may take some time to review.
Have you tested all these settings on Kicksecure yourself to ensure none of them cause any breakages for you?
Note: Some discussion may or may not occur on the Whonix forums.
Some seem extreme with no clear rationale provided. Such as:
blacklist amdgpu # Make this optionnal
blacklist iwlwifi # Intel wireless driver
Thanks for your replies. I edited the post as suggested by @souchikjoardar201. You right @adrelanos some are extreme like certain ppp, exfat/ntfs if want to be compatible with windows environment etc. @raja-grewal I gonna try this on kicksecure KVM/Vbox. I gonna make new post with results in a few days, you will see more clearly.
@MikeHorn-git I think the blacklist ones are extreme but as far as PPP and DVB/DVB-T and InfiniBand I'm not sure what issues these would cause if you disabled them.
What is the rational or reasoning behind those (PPP and DVB/DVB-T and InfiniBand) being disabled? Is there certain attacks that leverage those or is it just that they are oudated/old and and unused and could be used for attack surface?
Good question, the second option. Outdated/old and could be used for attack surface. PPP seems to be the worst suggestion among others, you right about possible issues that would cause.
So I try these with a kicksecure virtualbox. No issues at the moment. What are the tests I could use for more results ?
@EclipseBazooka
- I don't have issues. Do you have any suggestions for more advanced tests ?
- These modules are related to live TV.
https://github.com/Kicksecure/security-misc/pull/235 makes me question what the scope for kernel module blacklisting / disabling.
Some criteria is needed such as:
- Rarely used functionality.
- Known security issues.
Please suggest criteria.
Maybe good to reconsider the history of /etc/modprobe.d in security-misc. It was based on research / discussions / other distributions.
30_security-misc_conntrack.conf:## https://conntrack-tools.netfilter.org/manual.html
30_security-misc_conntrack.conf:## https://forums.whonix.org/t/disable-conntrack-helper/18917
30_security-misc_disable.conf:## https://forums.whonix.org/t/blacklist-more-kernel-modules-to-reduce-attack-surface/7989
30_security-misc_disable.conf:## https://madaidans-insecurities.github.io/guides/linux-hardening.html#kasr-kernel-modules
30_security-misc_disable.conf:## https://en.wikipedia.org/wiki/Bluetooth#History_of_security_concerns
30_security-misc_disable.conf:## https://security.stackexchange.com/questions/119712/methods-root-can-use-to-elevate-itself-to-kernel-mode
30_security-misc_disable.conf:## https://github.com/Kicksecure/security-misc/issues/215
30_security-misc_disable.conf:## https://en.wikipedia.org/wiki/IEEE_1394#Security_issues
30_security-misc_disable.conf:## https://www.kernel.org/doc/html/latest/driver-api/mei/mei.html
30_security-misc_disable.conf:## https://tails.boum.org/blueprint/blacklist_modules/
30_security-misc_disable.conf:## https://fedoraproject.org/wiki/Security_Features_Matrix#Blacklist_Rare_Protocols
30_security-misc_disable.conf:## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist-rare-network.conf?h=ubuntu/disco
30_security-misc_disable.conf:## https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598/233
30_security-misc_disable.conf:## https://www.openwall.com/lists/oss-security/2019/11/02/1
30_security-misc_disable.conf:## https://github.com/a13xp0p0v/kconfig-hardened-check/commit/981bd163fa19fccbc5ce5d4182e639d67e484475
30_security-misc_disable.conf:## https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Security_vulnerabilities
30_security-misc_blacklist.conf:## https://forums.whonix.org/t/blacklist-more-kernel-modules-to-reduce-attack-surface/7989
30_security-misc_blacklist.conf:## https://madaidans-insecurities.github.io/guides/linux-hardening.html#kasr-kernel-modules
30_security-misc_blacklist.conf:## https://nvd.nist.gov/vuln/detail/CVE-2018-11506
30_security-misc_blacklist.conf:## https://forums.whonix.org/t/blacklist-more-kernel-modules-to-reduce-attack-surface/7989/31
30_security-misc_blacklist.conf:## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist-framebuffer.conf?h=ubuntu/disco
30_security-misc_blacklist.conf:## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist.conf?h=ubuntu/disco
30_security-misc_blacklist.conf:## https://git.launchpad.net/ubuntu/+source/kmod/tree/debian/modprobe.d/blacklist-ath_pci.conf?h=ubuntu/disco
But it seems now we're getting ahead / taking the lead / blacklisting / disabling everything and the kitchen sink without much rationale / error handling.
Will comment in https://github.com/Kicksecure/security-misc/pull/236 too.
I would agree that some of the discussion has been based on research and other distributions. However, the majority of kernel modules actually disabled have been on the basis attack surface reduction by blocking "obscure/rare/uncommon/legacy" networking protocols and file systems".
See https://github.com/Kicksecure/security-misc/commit/e0aa67677d3561cae6544c24e12021dd04f26133, https://github.com/Kicksecure/security-misc/commit/a813e7da07a39e96e0cd7937aee7568307a00287, https://github.com/Kicksecure/security-misc/commit/18d67dbc5309a2403bece92881e671f46dc27f86, https://github.com/Kicksecure/security-misc/commit/61ef9bd59f9ff39c140f782ff5b41d0a3c6d97bc, https://github.com/Kicksecure/security-misc/commit/ef1ef9917d896f1cd837f399def6a75704e9bfd2, https://github.com/Kicksecure/security-misc/commit/06f13bb766bd84182331aeb1632b917de4b36020, and many more.
I strongly agree that we should develop some sort of criteria.
It needs a rationale. If an incoming incoming network package can result in auto loading a kernel module (such as IRC), which may then be vulnerable, we have a good rationale to block loading it.
Need to consider the code flow. Can a non-root user make a kernel module load and would that widen the attack surface by loading a module which is most likely just legacy? Then we have another good rationale to block loading it.
Blocking obscure file systems is also good because if a device gets connected with a nowadays obscure / unexpected filesystem.
A good reason to block a kernel module is also if security researcher(s) make a good argument why that should be done.
However, common functionality should not be blocked.
As said in https://github.com/Kicksecure/security-misc/issues/239:
Abundance of caution can't really be a suitable criteria because there a hundreds or thousands of kernel modules. That's too big in scope for a a security "
miscellaneous" project. That would best maintained by a separate project.
Through issue:
- https://github.com/Kicksecure/security-misc/issues/271
I learned, the only thing we blacklisted was snd_intel8x0.
This had resulted in multiple kernel modules not loading.
ac97_bus
joydev
snd_ac97_codec
snd_intel8x0
snd_pcm
So in theory, one could report a bug:
You are blacklisting
snd_intel8x0but fail to blacklistac97_bus,snd_ac97_codec,snd_pcm.
This would be technically correct.
But who has really the time to read through thousands of kernel modules and build a complete list? I don't think we have this capability.