Accurate Run-time Kernel Module Checking

Steve Grubb sgrubb at
Mon Aug 27 19:00:32 UTC 2012

On Monday, August 27, 2012 02:34:29 PM Mike Palmiotto wrote:
> All,
> Just wondering what the community thinks about the appropriate standard
> for disable kernel modules.  All of these solutions seem valuable in
> their own right, but as far as I know, none of them ensure the actual
> presence/absence of kernel modules at run-time.

This is the way it is for all guidance settings. Almost all checks are for 
what is on-disk to ensure that when a system boots up, it will go into the 
proper state, For example, sysctl's are checked in /etc/sysctl.conf. It could 
have a follow up test that pulls values from /proc/sys.

But then think about the daemon do you really know what ciphers 
or protocols sshd is really enforcing?

> 1) rdblacklist=[kernel_module]
> 	- I know this only prevents loading of the module in the rd=ramdisk,
> but how does this affect dracut at runtime?
> 2) /etc/modprobe.d blacklists
> 	- This approach is very similar to /bin/true.
> 3) install kernel_module /bin/true
> 	- This ensures that an entry in a textfile is present, but what if
> someone runs insmod on a kernel_module?  This will not reflect the true
> status of the kernel module in the system.

it should fail because the installation method is not a true installation 

> 4) /proc/ksyms
> 	- Seems to be the most accurate reflection of the current system
> status, though I'm no expert, so call me out on this.

This is the way to see what is in effect at the moment.

> I look forward to your input.

I think there is merit to checking what is being enforced. I think its a whole 
can of worms to open, though. Some subsystems don't have OVAL objects where 
this can be done easily...iptables and audit come to mind. I think the focus 
for most guidance is about on disk. I don't know if this fits in the OVAL for 
forensics use case. But I have a feeling its another project itself.


More information about the scap-security-guide mailing list