On Tuesday, 03/21/2006 at 06:46 EST, "Meanor, Tim" <[EMAIL PROTECTED]> wrote: > They were talking about LAuS (Linux Audit Subsystem). I'm not sure > exactly what they were talking about, but by default auditd keeps 4 > (preallocated) 20M binary files in which it stores it's audit info. > When one of the binary files fills up, it writes the data to a unique > file (save.1, save.2, etc, etc) and then switches to the next binary > file. Over time, this will fill up /var/log/audit.d with these save > files. If there is not enough available filesystem space to write the > save file, auditd will suspend until there is enough room. When auditd > is suspended, anything trying to write an audit event (sshd, for > example) goes to sleep until auditd starts accepting events. The guest > will appear to be hung, but it is actually still functioning (albeit > with limited usefulness). This is fixed by cleaning up /var then kill > -HUP the pid of auditd.
Sorry for the late post...catching up.... Actually, the "fix" is to write the files in audit.d to some other permanent storage and then clean up the files. Killing auditd or just erasing the audit trail kind of defeats the purpose of auditing, doesn't it? FWIW, ISO/IEC 15408 (Common Criteria) requires a system to stop new logins and deny access to resources if audit records cannot be written. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
