Re: [logs] adduser log

From: Paul Robertson (probertsat_private)
Date: Wed Jan 22 2003 - 10:59:07 PST

  • Next message: Bennett Todd: "Re: [logs] adduser log"

    On Wed, 22 Jan 2003, Tom Perrine wrote:
    > 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.
    Execve was the only one I'd targeted, though the module I ripped the code 
    out of was hooking other system calls in order to stop shellcode working 
    against network daemons[1].
    >     >> 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.
    I'm simply kloging the information.  It's relatively expensive compared to 
    making a real decision on the data and carrying on, the original module 
    wasn't measurable- and it hooked the multiplexed socket syscall as well as 
    > 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()? :-(
    The "real" solution for people who need that is a trusted system with it 
    built in.  RSBAC ( is my favorite one of those, but 
    there's a lot of admin overhead involved in that.
    > 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?
    I don't even know what a typical system is these days.
    > 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.
    Indeed.  I'm a big fan of small bite-sized solutions for most things, my 
    intent isn't to replace a B-level system, and I'm pretty 
    anti-creature-feep.  Since I had the code, and it was mostly a matter of 
    ripping things out, I offered it up.  Testing will tell how expensive it 
    is (as well as if klogd handles things well.)
    Paul D. Robertson      "My statements in this message are personal opinions
    probertsat_private      which may have no basis whatsoever in fact."
    probertsonat_private Director of Risk Assessment TruSecure Corporation
    LogAnalysis mailing list

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