ComplianceAsCode
Consider checking kernel modules in run-time
Description of problem:
Currently (0.1.69) the kernel_module_disabled template, used by many rules checks the configuration files to ensure the module is persistently disabled. However, it is possible the module is properly disabled in configuration files but still loaded in run-time.
Proposed change:
Similarly to what is done with services in service_disabled template, we should consider implementing a similar approach for Kernel Modules.
Differently than services, OVAL does not have an object definition for run-time modules.
One alternative to consider is to consult the /proc/modules file, as suggested in https://github.com/ComplianceAsCode/content/issues/2651#issuecomment-373443778
References:
- CIS RHEL9 - 1.1.9 Disable USB Storage
- https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2022-12-06/finding/V-230503
- Thanks @sean797 for bringing this topic to discussion in https://github.com/ComplianceAsCode/content/issues/2651
Additional Information/Debugging Steps:
This change would be valid for many products. Note that not all Benchmarks require to check run-time.
The following rules are using this template:
- kernel_module_atm_disabled
- kernel_module_bluetooth_disabled
- kernel_module_can_disabled
- kernel_module_cfg80211_disabled
- kernel_module_cramfs_disabled
- kernel_module_dccp_disabled
- kernel_module_firewire-core_disabled
- kernel_module_freevxfs_disabled
- kernel_module_hfs_disabled
- kernel_module_hfsplus_disabled
- kernel_module_iwlmvm_disabled
- kernel_module_iwlwifi_disabled
- kernel_module_jffs2_disabled
- kernel_module_mac80211_disabled
- kernel_module_rds_disabled
- kernel_module_sctp_disabled
- kernel_module_squashfs_disabled
- kernel_module_tipc_disabled
- kernel_module_udf_disabled
- kernel_module_usb-storage_disabled
- kernel_module_uvcvideo_disabled
- kernel_module_vfat_disabled
I also noticed something else, kernels that have a given module not compiled at all still trip up the rule - for example kernel compiled with CONFIG_CRAMFS=n still trips up the rule.
Would it be ok to extend existing check to see if a given module is at all available on the system? Because likely no modprobe snippet is needed then.
