[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Handling disk full & No Kernel resources





--- Mounir Bsaibes <bsaibes 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 us ibm com



Casey Schaufler <casey schaufler-ca com>
Sent by: linux-audit-bounces redhat com

01/05/2005 10:40 AM

Please respond to
Linux Audit Discussion

To
Linux Audit Discussion <linux-audit redhat com>
cc
Subject
Re: Handling disk full & No Kernel resources






--- Mounir Bsaibes <bsaibes 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 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 redhat com
http://www.redhat.com/mailman/listinfo/linux-audit


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]