Re: [logs] adduser log

From: Tom Perrine (tepat_private)
Date: Wed Jan 22 2003 - 10:50:49 PST

  • Next message: Paul Robertson: "Re: [logs] adduser log"

    >>>>> On Wed, 22 Jan 2003 10:11:46 -0500, Bennett Todd <betat_private> said:
        BT> 2003-01-21T20:14:20 Paul D. Robertson:
        >> So, I could offer up a module that logs all execve() calls to    =20
        >> klogd in a few days (I'd want to test it for 3-4 days continuosly=20
        >> since it's kernel memory before handing it out,) and you could   =20
        >> play from there, anything else takes more time and research than =20
        >> I have free at the moment.                                       =20
        BT> I'd like that. I'd use that. I think that ought to be submitted for
        BT> inclusion in the stock Linux kernel, it's so useful.
    As a configurable option, absolutely.  There's *lots's* of prior art,
    as far back as Multics, Secure VMS, VM/370, etc.  Its a useful
    feature, with a few caveats...
    It really depends on whether you do just exec() or other system
    calls.  Doing more than just a few calls will get ugly, really fast.
        >> I'd expect that to generate *lots* of log data though, so it's
        >> probably not all that useful.  If we nuked logging /bin/sh it
        >> might not be all that horrendous though...
    In Orange Book days, some interpretations of "audit" implied that
    logging all system calls (including args) was necessary.  (It wasn't,
    by the way.)  This lead to *serious* performance problems, but not
    from the actual "logging" of the system call.  Its in the movement of
    that data out of the kernel into some user-space location, and moving
    all that data "someplace else" that adds the overhead.
    Its not clear (yet), if this would be a problem if you just did
    exec(), but I *could* also argue that if you are doing exec(), why not
    chmod() and chown(), and then open()? :-(
    Consider that lots of kernels are idling at hundreds or thousands of
    system calls/sec.  That adds up fast.  Any idea what the exec() rate
    is for a typical system?
        BT> Why special-case anything. Logging the invoking pid, [e]uid, gids,
        BT> cmd, argv, and env is far, far less work than implementing an exec,
        BT> so the performance impact should be small.
    Yes, the implmentation in the kernel is not very bad.  Its the
    movement of that data that explodes.  Note that exec() is one of the
    most expensive system calls there is, so saying that your added
    overhead is compariticely low isn't saying an awful lot :-)
    I know of a DARPA/Navy project right now that is looking at this
    (logging all system calls, not just exec() ) for some "secure Linux"
    (started with SE Linux).
    They've instrumented their kernel almost exactly like we're talking
    about (havn't submitted kernel changes back, yet), and they
    immediately ran into performance problems.  Even though they are
    willing to spend a lot of performance to get LOTS of audit, they are
    having to re-think some of their approaches.  I'll see if I can get
    one of those developers to shoot a note this way...  I'm pretty sure
    thay haven't published anything yet, its a fairly new project, IIRC.
    In short - its a great idea, as long as you can turn it on and off as
    needed and if you can get the data out of kernel space and do
    something with it quickly enough.
    Tom E. Perrine <tepat_private> | San Diego Supercomputer Center     | 
    LogAnalysis mailing list

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