Crispin / Casey, (All: For info - this may generate some useful discussion), Crispin, when replying to Casey's email, said: > Rather, *Linus* is hostile towards audit, I'm not sure that hostile would be the right word, but if he questions the usefulness of putting a large number of fairly intrusive hooks into the kernel, just to support auditing, he's quite right to do so! :) Despite the fact that we're running with a project that implements an auditing subsystem, we're certainly not under any illusions as to it's broad popularity ;) The fact is that (right now) somewhere near 90% of systems are not going to be interested in running any form of operating system auditing. Of the remaining 10% or less (which generally comprise banks/financial houses, medical data (or other private data) repositories, defence sites, govt. departments, etc) - only a small percentage will actively make use of auditing to enhance their security. As such, adding mandatory bloat to the kernel, to cover (at a guess) 2% of all users, or less is a pretty poor value proposition. However, for perhaps the remaining 1-2% of sites that are interested in Linux, an audit subsystem is a mandatory precursor to putting operational applications and data on Linux. So why bother with auditing on Linux at all? Well, some of the sites that are interested in auditing are organisations like the Aust & US DoD, NSA (US's infosec authority), and big banks (that are starting to throw linux on big-iron machines that used to run MVS). Linux has some great features from a security perspective, and having Linux loose out to another O/S in these Key security-critical organisations because it lacks an effective auditing subsystem is a bit sad. That's why taking over sys_call_table entries was such a (Theoretically!) nice solution. It added ZERO bloat to the kernel, and your audit subsystem could exist as a module - so that only organisations that were really interested in auditing needed to install. In practice however, sys_call_table is a minefield of potential problems - particularly on SMP machines. So now we're at a crossroads, and I would welcome any suggestions as to the best way forward. 1) Integrate SNARE into the kernel. - This is bad in some ways - particularly due to the 90%/10% reasoning given above. However, it does give Linux a "audit available by default" claim-to-fame, in order to compete against operating systems such as Solaris / Windows / AIX, etc - where turning on the native auditing subsystem is as simple as a couple of mouse clicks (or /etc/security/bsmconv in the case of solaris). However, it may be appropriate for some distributions that cater to the 'security critical' customers (eg: Redhat advanced server, immunix, Mandrake-security, etc.) 2) Try and move down the LSM path - Implement auditing where it's feasible, noting that we're not going to receive some events (eg: file open failure due to 'file not found') that never reach LSM. - Gradually work towards adding additional LSM hooks for more comprehensive coverage. 3) Pull back from the kernel side, and work with Casey and the guys at SGI to use their LSM backend, and provide a SNARE audit-daemon and GUI implementation at the front-end. 4) Integrate snare into major distribution kernels post-release, and offer alternative kernel's (source + binary) for the major distributions. (Note: this is a bit of a maintenance nightmare). 5) Some other path? (Suggestions welcome!) Thoughts? Regards, Leigh. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jan 29 2003 - 17:24:22 PST