0.9.6 has now been built, and is available from the intersectalliance site. If you're interested in building a kernel for your distribution, please contact the authors!
Re: LKMs - an enabling technology
> There's the
> inherit problem of loadable modules that
> you cannot be certain of the integrity
> of the code, assuming you allow modules
> to be inserted and unloaded at any point
> while the system is running.
Towards this end, the Snare Agent for Linux is now available as a kernel patch. A lot harder for individuals to install, but perhaps a little easier for distributions to directly integrate (eg: Redhat Advanced Server, SuSE SLES, Debian).
> As root on a Linux system, or as
> Administrator on a WinNT box, you have
> ultimate control over devices, memory
> and processes. There are MANY more ways
> of disrupting security technologies than
> simply removing a module, including (but
> not limited to):
Valid points. However, my main concern is that modules add another problem that I believe to be more serious than simply disrupting the operability of the security system. All the examples you provided can be detected very quickly by an admin. The more serious problem, in my opinion, is being able to alter the code of SNARE while the system is running, completely oblivious to the administrator.
So while all of the other things you talked about can be fixed fairly easily with the use of some other software to provide access control, there's the inherit problem of loadable modules that you cannot be certain of the integrity of the code, assuming you allow modules to be inserted and unloaded at any point while the system is running.
A false sense of security is worse than no security.
LKMs - an enabling technology
As root on a Linux system, or as Administrator on a WinNT box, you have ultimate control over devices, memory and processes. There are MANY more ways of disrupting security technologies than simply removing a module, including (but not limited to):
- Unmounting the disk that audit data is written to.
- Linking the audit log to /dev/null
- Rebooting with a bootable linux CD, and installing a custom kernel.
- Changing the audit configuration so that nothing is audited.
- Many more.. but as an author of the grsecurity, you're probably already aware of these.
Integrating audit directly into the kernel as a patch is definately an option that will restrict the ability to terminate the core audit capability, but not one that stops any of the other alternative compromise mechanisms mentioned above. Solaris implements much of the BSM audit subsystem in the kernel, but a simple 'audit -T' will stop all auditing. AIX implements auditing in the kernel, but remove /dev/audit, and it all dissapears.
The point is, that root has ultimate control over the system, and can ultimately get around the security countermeasures that are put in place. We hope that SNARE will help systems and security administrators perform appropriate auditing and host-based intrusion detection, to catch users before they make it to root.
Additional countermeasures can be put in place to guard against some of the security threats, eg: The ability in SNARE to send audit data in real-time over the network to a central audit collection system will allow an administrator to perform forensic analysis on the compromised machine, since the attacker doesn't have the chance to remove the logs - they're already off the system. The addition of the SELinux access controls can limit the ability to remove modules by administrators. Append-only file-systems can assist with file erasure issues.
However, one of the core goals of SNARE is to make auditing less of a chore, and more of a resource. In order to make auditing easier, we wanted to to make sure that SNARE could integrate into existing distributions, without requiring a kernel recompile. This has allowed system administrators a easy path to (hopefully) better security, without needing to move away from their normal distribution kernels.
SNARE is just one piece in the security jigsaw. A lot of other pieces are needed to implement appropriate security. However, we think that it provides an important capability, in an appropriate format, which is why we decided to release the project as open-source.
You tout being a dynamic loadable kernel module (as many other security projects have fallen into the same trap), however, since the software is supposed to aid in intrusion detection, why does it offer no protection against someone gaining root and simply unloading your module? There's no integrity of the auditing system if you use an LKM.
An open, cross-platform journaling program.
A scientific plotting package.