Kernel module checks should use lsmod

[sean797]

Description of problem:

Kernel module checks for config in files, really it should use lsmod to view loaded kernel modules. There are many ways to disable kernel modules, the SCAP report should show as pass regardless of how the desired result has been achieved.

For example:

xccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled checks for install usb-storage in a few different directories. This this can (and IMO should) be blacklisted using blacklist usb_storage but could be done in many ways.

SCAP Security Guide Version:

scap-security-guide-0.1.33-6.el7_4.noarch

Operating System Version:

RHEL 7.4

Steps to Reproduce:

1. sudo echo "blacklist usb_storage" >> /etc/modprobe.d/blacklist.conf
2. sudo modprobe -r usb_storage
3. lsmod

Actual Results:

Expected Results:

Addition Information/Debugging Steps:

[redhatrises]

@sean797 can you be more specific? OVAL does not use lsmod.

[sean797]

@redhatrises that is my point, that is the definitive way to check is lsmod but currently it checks using a regex for install usb-storage /bin/true.

[redhatrises]

@sean797 using command line tools, that would be correct. Checking runtime configuration can be done; however in the security realm, you should do both. That said, using the OVAL language, how would you use lsmod?

[sean797]

using the OVAL language, how would you use lsmod?

Sorry I am not familiar with OVAL language, if I was, I would submit a PR ;)

[shawndwells]

The first part of this seems actionable. The OVAL kernel module templates could be updated to keep failing if present in one of the various module config files, and pass if module has been blacklisted through blacklist.conf. Would need to lookup ordering rules... e.g. if explicitly in blacklist.conf, but enabled elsewhere, who wins?

In regards to lsmod... that just parses the contents from /proc/modules. Additional checks could be created to parse /proc/modules to get the runtime modules.

[sean797]

@shawndwells do we even need to parse any config files? Sure the remediation script can add the config. Why would we care how the desired result has been achieved?

IMO we should only care that the module isn't loaded, we shouldn't care how.

parsing /proc/modules would also work :+1:

[shawndwells]

Things like OpenSCAP and Atomic Scan can be pointed at container registries. Those users want to ensure configurations are correct before starting the containers (especially from 3rd parties). Same thing with virtual machines.

That's why, wherever possible, the SCAP content checks for runtime config (e.g. /proc) and persistent (config file) settings as two separate rules. People who don't care/need both evaluations can easily customize the profile with something like SCAP Workbench.

[shawndwells]

FWIW, a good example is sysctl.

[redhatrises]

Plus if you think VMs and physical systems, someone could remove the configuration setting but not reboot the machine for a long time. Then when the machine is rebooted, the setting is not longer set.

[sean797]

Interesting, I've always seen OpenSCAP reports as a way of telling me if my system is complaint at the time I run the report. I think attempting to verify if a thing is going to be compliant in the future is a impossible thing to achieve, definitely very hard.

I kind of understand the use case about checking config before you start something, the problem we have is there are so many valid ways of doing something, for example all of these in /etc/modprobe.d/ or /lib/modprobe.d/ or /run/modprobe.d/ are valid:

• install usb-storage /executable/that/doesnt/do/anything
• blacklist usb-storage
• remove usb-storage

or even a cron entry like the following would be valid:

• @reboot sudo modprobe -r usb_storage

Obviously some ways are considered much better practice than others, but IMO we should not reply on best practices, we should report a pass or fail based on if the system is compliant, we shouldn't rely on the user doing something is a specific way unless we have no other option.

[marcusburghardt]

OVAL is a declarative language and does not expect to execute command for assessment. For assessments using scripts, SCE could be used: https://www.open-scap.org/features/other-standards/sce/

Also, the rules in general do what is requested by Benchmarks, like CIS, STIG, etc.

[shawndwells]

OVAL is a declarative language and does not expect to execute command for assessment. For assessments using scripts, SCE could be used: https://www.open-scap.org/features/other-standards/sce/

Also, the rules in general do what is requested by Benchmarks, like CIS, STIG, etc.

@marcusburghardt Can appreciate the desire to close tickets, but all that's needed here is to re-write the regex to evaluate /proc/modules. SCE is not needed.

[marcusburghardt]

OVAL is a declarative language and does not expect to execute command for assessment. For assessments using scripts, SCE could be used: https://www.open-scap.org/features/other-standards/sce/ Also, the rules in general do what is requested by Benchmarks, like CIS, STIG, etc.

@marcusburghardt Can appreciate the desire to close tickets, but all that's needed here is to re-write the regex to evaluate /proc/modules. SCE is not needed.

@shawndwells , the discussion was about lsmod and this is currently only achievable with SCE. After more than 5 years without any interaction in this issue, it is good to see new comments. @sean797 , I considered the comments here and created a more specific issue: https://github.com/ComplianceAsCode/content/issues/11050

Thanks for all who collaborated in the discussion.

Closing this issue in favor of https://github.com/ComplianceAsCode/content/issues/11050