Accurate Run-time Kernel Module Checking
sgrubb at redhat.com
Mon Aug 27 19:00:32 UTC 2012
On Monday, August 27, 2012 02:34:29 PM Mike Palmiotto wrote:
> 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 settings...how 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