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 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
method.
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.
-Steve