On Wed, May 29, 2002 at 12:12:12PM +0100, John Levon wrote: > On Wed, May 29, 2002 at 07:22:46AM +0530, Sridhar N wrote: > > > ok, I get your point. Well, assuming what you've given is general to all > > syscalls, is it possible to insmod the module once, with a enable/disable > > flag, so that when the IDS is to be switched on, i just enable the flag to > > enable filtering. And instead of removing the module, I just reset the flag. > > Of course, *all* syscalls *all* the time, have to go through my code, even if > > the IDS is off. That is an overhead and a drawback, but atleast I *think* > > that should be safe. Are my assumptions right ? > > Actually things are slightly better than that. You can still switch back > to the old system call pointers in the table, it's just you can never be > *completely sure* that you can unload the module. This is only correct on architectures where updating a function pointer is atomic (such as x86). IIRC, this is not the case on IA64, for example. The syscalltrack solution, btw, is to simply refuse to unload the hijacker module. It's only 20k and can be shrunk further, and that's a small price to pay for you data's assured integrity ;) -- Sunday 7 Forelithe 7466 http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
