handling disk full

[Mounir Bsaibes]

We are talking about 2 different things: 1) handling disk full 2) 
suspending the process whenever there are no kernel resources.

1) For handling disk full I am doing the following:
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 the processes.
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. 



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



Stephen Smalley <sds at epoch.ncsc.mil> 
Sent by: linux-audit-bounces at redhat.com
12/15/2004 12:09 PM
Please respond to
Linux Audit Discussion


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

Subject
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 
from
> 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 the audit
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 not a
> problem for CAPP compliance if those messages get discarded if there is
> 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 or
alternate interface. 

In any event, use of sigsuspend seems questionable.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency

--
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/20041215/9bac6caf/attachment.htm>