Re: c2 (or c2-like) auditing for Linux

From: Leigh Purdie (Leigh.Purdieat_private)
Date: Wed Jan 29 2003 - 17:29:57 PST

  • Next message: Valdis.Kletnieksat_private: "Re: c2 (or c2-like) auditing for Linux"

    Crispin / Casey, (All: For info - this may generate some useful
    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!)
    Leigh Purdie, Director - InterSect Alliance Pty Ltd
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Wed Jan 29 2003 - 17:24:22 PST