Handling disk full & No Kernel resources

[Mounir Bsaibes]

--- Mounir Bsaibes <bsaibes at us.ibm.com> wrote:
 
> 1) The first, is when the audit log is full and the
> audit subsystem cannot 
> write the audit record.


CAPP style audit trails (then known as C2) began
appearing in U2X systems in the mid 1980's. 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. One example I like to use
is inetd, which *must* be audited and which will
cause amazing (lack of) behavior if it's suspended.
Another of my favorites is the X server. Imagine
trying to free up audit space with that locked up.
U2X systems often offer the alternative of throwing
records away if space isn't available, although
CAPP really dislikes that option.

>> Another CAPP requirement is to configure a watermark for the audit log. 
Whenever, the watermark is reached auditd should start sending messages to 
the administrator. Obviously, we can't rely on the administrator taking 
action on receipt of the messages, the audit log can still be full. I like 
the idea of dropping the system to a single user mode for the admin to fix 
the problem. Alternatively, we can do as Valdis suggested pre-allocate the 
audit log. Then auditd can send AUDIT_SUSPEND whenever the log reaches the 
pre-allocated size - 3% for example instead of just waiting till the audit 
log is full.


> 2) The second, is when the kernel cannot allocate
> memory to generate the 
> audit buffer.

Oh, that's easy. The system must die at that point,
and the system must generate a core file for later
analysis. You are not allowed to lose audit data.
Plus, I suggest that there is no useful action you
could take that could reliably be expected to not
result in additional audit records.

>> The current implementation has a configuration option to panic the 
system whenever the audit records are lost. Is this acceptable?





Mounir Bsaibes
Linux Security
Tel:  (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes at us.ibm.com



Casey Schaufler <casey at schaufler-ca.com> 
Sent by: linux-audit-bounces at redhat.com
01/05/2005 10:40 AM
Please respond to
Linux Audit Discussion


To
Linux Audit Discussion <linux-audit at redhat.com>
cc

Subject
Re: Handling disk full & No Kernel resources







--- Mounir Bsaibes <bsaibes at us.ibm.com> wrote:
 
> 1) The first, is when the audit log is full and the
> audit subsystem cannot 
> write the audit record.

CAPP style audit trails (then known as C2) began
appearing in U2X systems in the mid 1980's. 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. One example I like to use
is inetd, which *must* be audited and which will
cause amazing (lack of) behavior if it's suspended.
Another of my favorites is the X server. Imagine
trying to free up audit space with that locked up.
U2X systems often offer the alternative of throwing
records away if space isn't available, although
CAPP really dislikes that option.

> 2) The second, is when the kernel cannot allocate
> memory to generate the 
> audit buffer.

Oh, that's easy. The system must die at that point,
and the system must generate a core file for later
analysis. You are not allowed to lose audit data.
Plus, I suggest that there is no useful action you
could take that could reliably be expected to not
result in additional audit records.


I realize that these are user unfriendly behaviors.
Audit trails with gaps are like movies edited for TV,
sometimes you loss critical plot elements. Linux
has so much going on and depends on so many system
processes that you won't get away with blocking.


=====
Casey Schaufler
casey at schaufler-ca.com


 
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

--
Linux-audit mailing list
Linux-audit at redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050105/7522f0e4/attachment.htm>