To: Linux Audit Discussion <linux-audit redhat com>
Subject: Re: handling disk full
Date: Wed, 15 Dec 2004 12:40:58 -0600
We are talking about 2 different things:
1) handling disk full 2) suspending the process whenever there are no kernel
1) For handling disk full I am doing
Whenever the disk full (or log reached
its limit) is detected the auditd sends an AUDIT_SUSPEND message
to the kernel. On receipt of this message the kernel will set a flag "disk_full_flag".
If this disk_full_flag is set audit_log_start will call audit_suspend
to queue the process in a wait queue. Whenever the disk_full_flag is reset
all the processes in the wait queue will be rescheduled.
2) For suspending the process whenever
there are no kernel resources:
I was thinking of using sigsuspend whenever
audit_log_lost is called depending on the "failure flag". The
failure flag currently can be set ,only, to: do nothing, print a message
or panic. I was thinking to add a fourth option to this flag to suspend
sigsuspend puts the process in the TASK_INTERRUPTIBLE
state, the process will only wake up when a nonignored, nonblocked signal
is sent to it. From the dicussion so far this may not be a good way to
go about solving this requirement, specially if the process is holding
locks or whatever. I need to either add to this solution or come up with
a different one.
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes us ibm com
Stephen Smalley <sds epoch ncsc mil> Sent by: linux-audit-bounces redhat com
12/15/2004 12:09 PM
Please respond to
Linux Audit Discussion
Linux Audit Discussion <linux-audit redhat com>
Re: handling disk full
On Wed, 2004-12-15 at 13:01, Klaus Weidner wrote:
> Keep in mind that the CAPP audit requirements are fairly independent
> the SELinux uses of the audit subsystem.
> CAPP requires that specific actions don't complete if they can't be
> audited, and those events will in general occur from a syscall context
> where a sleep should not be a problem.
1) What does "can't be audited" mean - that we couldn't send
record to userspace or that it couldn't reach the disk?
2) Even from process context, you'd have to make sure that the caller is
never holding a lock when it calls audit_log*.
> The events generated by SELinux are not required by CAPP, and it's
> problem for CAPP compliance if those messages get discarded if there
> no room for them and the kernel can't sleep.
Possibly, but audit_log* can't automatically detect whether it is safe
to sleep. Caller will have to provide that information via a flag
In any event, use of sigsuspend seems questionable.
Stephen Smalley <sds epoch ncsc mil>
National Security Agency
Linux-audit mailing list
Linux-audit redhat com