On Wed, 2005-01-05 at 08:40 -0800, Casey Schaufler wrote:
--- Mounir Bsaibes <bsaibes(a)us.ibm.com> wrote:
> 1) The first, is when the audit log is full and the
> audit subsystem cannot
> write the audit record.
With 20 years experience under our belts, the only
behavior that has ever been considered reliable is
for the audit deamon to send the system into
single user (or turn it off) when audit space is
not available. There are too many interdependencies
between processes and system operation to suspend
individual processess.
I'd have to agree with Casey here - Trying to block individual processes
(or even block all but a few 'special privileged' processes) sounds like
we're asking for a world of hurt - the equivalent of database deadlocks
are likely to occur unless we're VERY careful.
Remember, that of the tiny percentage of users who are likely to
activate CAPP-style auditing on their linux box, an even smaller
percentage of those, would ever be interested in a 'halt on audit fail'
option for their systems. Single-user is actually a pretty reasonable
fallback position, as opposed to a 'halt all processes' feature, which
could result in potentially nasty disk errors - particularly when
considering the 'feature importance' for most users.
Irix actually has one of the more sane audit implementations that I've
seen over the years. Good API, reasonable base utilities, good config
file layout (though, creating new audit classes
in /etc/security/audit/config is still an arse, Casey - and dynamically
turning on events using the API is challenging ;).
Though I'm not advocating wholesale feature duplication, there are
certainly a few things worth looking at in Irix - and the fallback to
single user is one worth considering.
Note though, that most operating systems either 'pre-buffer' a chunk of
disk space, or have a bit of 'wiggle space' in their disk space
availability detection mechanisms.
Solaris's auditsvc() system call, for example, can terminate when there
is a configurable number of blocks remaining (which should allow the
last few events to be written out before halting the OS).
IIS Web Server pre-allocates 2k chunks of whitespace in a file at a
time, and then gradually replaces the whitespace with real data.
I don't think that either of these approaches are optimal, but perhaps
zapping back to single user a few k/meg before disk space is full, may
be appropriate - rather than waiting for the last minute.
Regards,
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/