>>>>> 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 http://www.sdsc.edu/~tep/ | _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Jan 22 2003 - 11:17:36 PST