Security Auditing subsystem for Linux - request for advice/assistance
Regular readers of the lkml may have picked up a few references to the 'snare' auditing subsystem previously on this list (There's a link at end of this post for those who want to click through to search).
Snare has been in low-priority development for a fairly long time now, first as a kernel module that intercepted system calls via sys_call_table (I know, the 7th deadly sin.. we've repented), and more recently, as a kernel patch / audit daemon combo.
However, the requirement for an operational auditing subsystem seems to be ramping up pretty quickly, as government departments, and big organisations that need to meet government standards relating to computer security, start to adopt Linux in a big way.
We now have a bunch of organisations implementing snare internally (various banks and health-care providers, quite a few universities, most of the big defence/aerospace organisations, a fair number of govt departments, etc..). A few distribution vendors (RHAS/SLES) have also aparently received requests from some of their big customers to integrate snare into their releases.
As such, recognising that there are MANY people out there with a heck of a lot more kernel coding experience than the two core snare developers, we were hoping that some kind souls would offer a bit of assistance in cleaning up the code with a view to making things more streamlined / robust. If the code makes it up to spec, and enough people think it's worthwhile, kernel integration later on down the track may be an option also (2.7? Sooner? Suggestions welcome).
So, down to the specifics:
Snare provides an auditing subsystem for Linux, attempting to follow the general intent of C2/CAPP to provide a (hopefully) REASONABLE level of security, without impacting too significantly on either system performance, or security administrator resources.
The two developers of Snare have a fair bit of experience on the other end of logging / audit trails / forensics (Solaris BSM, AIX, Unicos, ACF2/RACF, Win EventLog, Firewalls too numerous to name, and so on), and can hopefully bring this experience to developing an audit subsystem that finds a reasonable middle-ground between "technically perfect but functionally useless", and "great information, but untrustworthy data".
The current implementation has a few areas that would really benefit from a bit of care-and-feeding from an experienced kernel hacker. In particular:
* Filenames
- Grabbing the REAL source / destination path for file-related events,
regardless of:
a) Whether the system call succeeds or fails
b) Symlinks, links, mountpoints, chroot's
* Opportunities for the user to shift paths between the auditapi copy from userpace, and the kernel copy from userspace, implying that the user may chmod /etc/passwd, whilst the auditapi reports a chmod of /tmp/goo (for example).
* Memory
- snare currently uses a 'rubber-band' linked list which soaks up
memory when the user-space audit daemon isn't fast enough to read events. Although there's a high-water mark, personalising it to each system (ie: memory availability) isn't happening.
* Potentially many other areas.
- LSM integration for some calls, if viable?
- General 'gotchas' - stuff that might be pretty clear to a
experienced kernel coder, that we haven't picked up.
So, if you're willing to take a peek at the code, and contribute a few code changes, please take a look at the following URL for a patch against stock 2.4.22 (url provided due to size of patch - about 93k).
http://www.intersectalliance.com/projects/Snare/Download/kernel-patch/SNARE-0.9.5b.diff
Audit daemon for this version of the patch, if you would like to test snare (includes audit.conf):
http://www.intersectalliance.com/projects/Snare/Download/kernel-patch/auditd-0.9.5b.tar.gz
More general info:
http://www.intersectalliance.com/projects/Snare/index.html
Alternatively, if any existing maintainer is interested in adopting snare, leaving us to play with the userspace audit daemon / GUI, please let me know!
Regards,
Leigh.
- - -
Search for snare on lkml:
http://www.google.com/u/iuussg?as_oq=snare&sa=Google+Search&domains=uwsg.iu.edu&sitesearch=uwsg.iu.edu&as_epq=hypermail%2Flinux%2Fkernel
Note: This email address is valid, but temporary only; it will probably dissapear approximately a month after this post. More permanent contact details available from http://www.intersectalliance.com/contact.html
Signature · 2 lines
Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/
Quoted 10 lines · Leigh Purdie
The current implementation has a few areas that would really benefit from a bit of care-and-feeding from an experienced kernel hacker. In particular:
* Filenames
- Grabbing the REAL source / destination path for file-related events,
regardless of:
a) Whether the system call succeeds or fails* Potentially many other areas.
- LSM integration for some calls, if viable?
You could do all of this from an LSM, except that the LSM exits are restrictive rather than authoritative. The upshot is that if an open() syscall fails due to file permissions, the LSM exit is never called, so you won't get an audit record that way - you need a more invasive patch for that.
Read the LSM archives, there's a lot of discussion of doing auditing in there, much of it revolving around the fact that proper audit makes for one hell of an invasive patch. Now that LSM is in for 2.6, it *might* be feasible to discuss audit for 2.7/8.
You probably want to port your patch to the 2.6 tree, as more development is going on there.