Re: Audit trails
Darren Reed (darrenr@cyber.com.au)
Mon, 2 Dec 1996 19:26:09 +1100 (EST)
A couple of things about process accounting on Unix:
* it can be turned on/off by writing to /dev/kmem
(yes, the hacker is root :)
* audit file is kept on disk and can be editted
As for system call auditting, under SunOS4 (at least), there is a particular
"userid" which tells the kernel "don't audit this". This is stored in ucred.
It may be possible to mess with system call auditting too, directly rather
than via the sytem call interface, although I've never seen the kernel
generate any syslog/console messages because of it.
I've written programs to turn on/off process accounting silently as well
as set the relevant id in the ucred structure.
Using kernel security levels or other methods to protect process auditting
by disabling writing to /dev/kmem reverts it to protecting the logs in
which notification of process accounting are kept (you can run a program
which does "while (fork() == 0) exit(0);" to chew up the space on the
partition where the "pacct" file lives, in between runacct/turnacct
invocations).
For system call auditting, the same problem exists of log space filling up
the disk. Even HP-UX (which has a daemon to monitor disk space usage and
will roll logs over) is not immune to this attack where useless information
either fills up or overwrites useful information.
So...at worst, they aren't going to give you any information, and at best,
you know someone has paid a call due to disk space problems.
Effectively, once they get root, the game is over. Whether or not process
accounting and system call auditting can give you enough information to
detect a possible attack is another. You might spot someone running Crack
or similar (high cpu usage).
Darren