StMichael is a LKM that attempts to provide a level of protection against kernel-module rootkits. It provides this protection by monitoring various portions of the kernel, and optionally the entire kernel text itself, for modifications that may indicate the presence of a malicious kernel module.
If rootkit-like activity is detected, StMichael will attempt to recover the kernel's integrity by rolling back the changes made to a previously known-good state.
The following is a brief list of the capabilities of the StMichael kernel module:
-- Can generate and check MD5, and optionally SHA1, checksum
of various kernel data structures, such as the system call
table, and filesystem call out structures
-- Can checksum (md5 only) the base kernel, and detect modifications
to the kernel text such as would occur during a silvo-type attack.
-- Can backup a copy of the kernel, storing it in a weekly encrypted
form, for later restoration if a catastrophic kernel compromise
is detected.
-- Can detect the presense of simplistic kernel rootkits upon
loading.
-- Can modify the linux kernel to protect immutable files
from having their immutable attribute removed.
-- Can disable write-access to kernel memory through the
/dev/kmem device.
-- Can conceal the Stmichael module and its symbols.
-- Can monitor kernel modules being loaded and unloaded to
detect attempts to conceal the module and its symbols, and
attempt to 'reveal' the hidden module.
NOTICE: This is experimental software. As such it may cause your kernel to crash, particularly when deployed on systems with non-standard kernel patches or kernel modules.
These non-standard patches include modifications made by
major distributions, additional security pactches, as
well as any home-brew patches you may use.
If you experience problems with StMichael and a non-standard
patch or kernel module, contact the author, and together
we can attempt to isolate and rectify the conflit.
The Saint Michael kernel module needs to be configured prior to its building. The "./configure" script is included to generate the configuraton for the StMichael kernel module.
After running "./configure" your configuration will be stored in a "Makefile.in" file. This file is called by the Makefile to set the definitions that control the compilation process.
Once the Makefile.in file has been generated, run "make" to build the kernel module.
**WARNING: It is strongly recommended the following command not be done **WARNING: on systems opperating in a production mode. If there are **WARNING: incompatabilities between the running kernel and StMichael, **WARNING: the entire system could crash or become unstable.
**NOTE: Once Loaded, StMichael does not have any mechinism **NOTE: that may be used to unload it. This has been done **NOTE: on purpose. To remove StMichael, it will be necessary **NOTE: to reboot the system.
To test the module, run "insmod ./StMichael.o"
This will load the StMichael kernel module with the configuration defined earlier.
If everything appears to work properly, you may want to play with some of the DEMO attack scripts.
**WARNING: Do not run the DEMO attack scripts on a production system. **WARNING: Some of the demo attacks modify the kernel in ways that **WARNING: could cause the system to become unstable if StMichael is **WARNING: not loaded or not opperating properly.
When deploying StMichael in a system, the module should be loaded at the first possible moment. One way of doing this would be to load the module prior to entering the initial runlevel. This is acomplished by adding the following line to /etc/inittab, and assumes that the compiled StMichael.o file has been copied to /lib/modules.
sm:35:once:/sbin/insmod /lib/modules/StMichael.o
**NOTE: This line should be added before the rc.sysinit script runs.
After loading, StMichael will output events to the kernel logging facility.
This section documents known issues and incompatabilities between Stmichael and other kernel patches and modules. It is my hope that this listing will shrink, as others and myself have a chance to review and debug the issues.
-
PCMCIA-CS
There have been some issues with PCMCIA-CS and StMichael. The issue seems to be that loading the pcmcia-cs modules into the kernel modifies the system calll table. These are legitimate modifications.
Simularly, removing the pcmcia modules from the kernel (even autoclean) would remove these system calls.
In the first case, the effect of StMicheal flagging these as rootkit activity and reversing the changes has little effect other then disabling the pcmcia subsystem.
In the latter case, the effects can be catastrophic. If calls are made to the system call -- the function that is in the sys_call_table points to unallocated portions of ram. The effects of calling this can range from OOps-ing the system to a potental avenue for malicious code to be executed.
To exploit this, malicious code would have to be overlayed on top of the exact place where the original pcmcia functions were. This should be considered difficult to non-trivial, but possible.
It is not recommended, at this time, to use StMichael on a laptop that loads kernel modules for PCMCIA support, or any other service that installs or removes new system calls.
-
GrSecurity
If StMichael is loaded on a system that is using a grate security kernel patch, StMichael may Oops. This Oops occurs on kernel load.
At this time, the cause of the problem is unknown.
-
-ac kernels.
The alan cox kernel serise seems to be making modifications to the 2.4.XX memory manager. These modifications may conflict with StMichael, and cause it to fail to compile.
StMichael 0.10 has been modified to work with the 2.4.19-pre3-ac3 kernel patch. The compile time option, -DACKERNEL, turns on this support.
Depending on the changes in future ac kernels, other issues may crop up. I do not monitor the ac kernels, so if you run an -ac and experience problems -- let me know. I will be glad to work with you to identify the issue.