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 execve > 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 (http://www.rsbac.org) 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 ----------------------------------------------------------------------------- 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 LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Jan 22 2003 - 11:22:28 PST