add support for blocking kernel modules

[bcressey]

Issue number:
Fixes #2235
Fixes #2236

Description of changes:
Provide a settings API for allowing or blocking specific kernel modules.

Testing done:
Confirmed that the new settings are available on upgrade, and cleaned up properly on downgrade.

Blocking a module rewrites modprobe.conf:

# apiclient set kernel.modules.sctp.allowed=false
# cat /etc/modprobe.d/modprobe.conf
install sctp /bin/true

A blocked module isn't loaded:

# modprobe -v -n sctp
install /bin/true

# modprobe sctp
modprobe: ERROR: Error running install command '/bin/true' for module sctp: retcode 127
modprobe: ERROR: could not insert 'sctp': Invalid argument

Allowing a module rewrites modprobe.conf:

# apiclient set kernel.modules.sctp.allowed=true
# cat /etc/modprobe.d/modprobe.conf
<no output>

An allowed module can be loaded:

# modprobe -v -n sctp
insmod /lib/modules/5.10.118/kernel/net/sctp/sctp.ko

# modprobe sctp
# grep sctp /proc/modules
sctp 434176 26 - Live 0xffffffffc0745000

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[bcressey]

The 127 return code for a blocked module happens because kmod uses system() to invoke the install command, which tries to run a shell, which isn't available in Bottlerocket.

This seems OK to me even if it's a little incongruous with the expected result of using /bin/true as the install command. That's a bit of an odd choice in its own right, but the various compliance benchmarks have settled on this as the "standard" mechanism, and I wanted to stay consistent with other distros here.

If the return code causes problems in practice, I can look at patching kmod to either always return true, or to use fork/exec rather than system(), but I feel like it's fine for now.

[arnaldo2792]

Have you considered having a blocked list? The current API implementation doesn't allow us to delete keys in the settings so if I want to allow a module in the current scheme, I have to set the allowed flag as true, which practically has the same effect as not having the setting at all. With this scheme, users could end up with many keys that they might not really need if they later decide to allow some of the previously blocked modules. But with the blocked list, they only have to modify one list, instead of many keys.

Also with a list, you can save yourself the extra if and unless statements in the handlebars template:

{{#each settings.kernel.modules.blocked}}
install {{this}} /bin/true
{{/each}}

And probably the extra KmodSetting type.

[bcressey]

I did consider it. The problem with lists is that they can't be incrementally updated; you have to reapply the current state with the desired additions or removals to get to the desired state. That makes it difficult to document independent steps for disabling individual modules, which is something I had to do for the CIS benchmark.

[cbgbt]

Nice! 🚀

[zmrow]

😶‍🌫️

[bcressey]

Rebased to fix the merge conflict around migrations.