CIS profile fails on absent filesystem modules

[bastien-jove-cbp]

Describe the bug

CIS profiles within automate may return failed checks about filesystem modules (1.1.1.X) when they don't exists on the target machine.

This test (for cramfs, but same thing is applicable to other FS modules) fails:

a = command("modprobe -n -v cramfs").stdout.scan(/.+/)
describe a do
  its("length") { should be > 0 }
end

On my EC2 instance using aws customized kernels I get as output:

# sudo modprobe -n -v cramfs
modprobe: FATAL: Module cramfs not found in directory /lib/modules/4.4.0-1074-aws

To Reproduce

Run a scan with the profile "CIS Ubuntu Linux 16.04 LTS Benchmark Level 1 - Server" on an EC2 instance from ubuntu official AMI

Expected behavior

The control description states:

Rationale: Removing support for unneeded filesystem types reduces the local attack surface of the server.

So when the module doesn't even exist on the filesystem I'd be expecting a successful check.

Versions (please complete the following information):

• OS: target OS is Ubuntu 16.04 on AWS
• Browser chrome
• Automate Build Number 20190501153509
• Profile version: 1.0.0-5

[stevendanna]

Thanks for the report! The profiles exist in another repository that is private, so I've opened an issue there as well; however, we'll be sure to update this ticket with any updates.

[james-stocks]

I have emailed CIS support about this, because the Chef profile implements exactly what CIS specify and we should get them to agree to change their recommendation before we deviate from their specification.

I notice that if the InSpec kernel_module resource is used then this works how you would like - a non-existent kernel module counts as not being loaded or loadable.

[james-stocks]

This is being discussed with CIS here: https://workbench.cisecurity.org/community/4/discussions/5031
(that URL will probably seem to be a broken link until you both sign up to the CIS workbench then join the Ubuntu community)

They will fix this in future Linux benchmarks. I am trying to confirm what logic they will change to for these controls, then we can overlay our InSpec controls.

[sdelano]

@james-stocks any update on this?

[rmoles]

Hi @sdelano, @bastien-jove-cbp it appears that the ubuntu profiles were updated a few months ago. In this update, we moved away from modprobe -n -v cramfs to using the inspec kernel_module resource.

Just to let you know, the controls in section 1.1.1.x, based on the CIS recommendations, also check that the kernel_module is disabled, whether it is installed or not. This will require install <_kernel_module_> /bin/true being added to /etc/modprobe.d/cramfs.conf

I would suggest updating to the latest ubuntu 16.04 profile to fix this issue.