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

Re: Handling disk full & No Kernel resources



On Wed, 2005-01-05 at 10:09, Mounir Bsaibes wrote:
> 1) For handling disk full:
> Instead of calling the audit_suspend from audit_log_start. I will call
> it from audit_syscall_entry 
> if the context is auditable. audit_suspend will place the process in a
> wait_queue until the disk_full_flag is reset. At that time all the
> processes in the wait queue will be awakened.

IIUC, almost all tasks are considered auditable at this point, unless
explicitly marked non-auditable via a filter.  Hence, this logic will
put almost all tasks to sleep in this scenario.  Only tasks that are
explicitly marked as not requiring any auditing will avoid this.

> Hopefully this is acceptable and I can go ahead and implement this. 
> 
> The question is how SELinux should treat its audit records in this
> case? For the current CAPP work this is not an issue. However, it will
> be for LSPP evaluation.

If any task can reach a SELinux hook (i.e. is not put to sleep on
syscall entry by the above), then the SELinux hook might still trigger
an audit message unless explicitly disabled via policy for that process'
domain (and the relevant object type, class, and permission).
 
> 2) For suspending the process whenever there are no kernel resources:
>     Audit_log_lost is called from many places for many reasons no
> memory, socket is busy, etc.. I need to think a little bit more about
> this. If we don't want to sleep in any audit_log* function. Any
> suggestion?

I think we need a separate interface for callers that can sleep.

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


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