[PATCH] LSPP audit enablement: storing selinux ocontext and scontext

Timothy R. Chavez tinytim at us.ibm.com
Thu Jul 28 16:12:02 UTC 2005


On Thursday 28 July 2005 10:49, Steve Grubb wrote:
> On Thursday 28 July 2005 11:27, Timothy R. Chavez wrote:
> > But audit_panic() doesn't just panic the system or it doesn't have to at
> > least.  You're able to set the 'audit_failure' such that when audit_panic()
> > is called it can fail silently, print to syslog, or panic the system.
> 
> Right, but audit_panic is reserved for use when the backlog overflows or rate 
> limit is too high. When you wrote the fs watch code, did you call audit_panic 
> when a buffer alloc failed? No, you failed the syscall. The behavior should 
> be consistent.

Yeah, I'm thinking I should be calling audit_panic() instead.  I think that the
correct way to handle such errors that occur _in_ the audit sub system.  Also, 
I fail silently if the audit_watch_notify() hook is called and it can not allocate
an memory to place on the audit context... the admin has no control over this.
At least with audit_panic they can specify how they want the system to fail.

Let's say our system is extremely stressed out and we fail a memory
allocation that's nonfatal... that record is missed but the system is still running 
when really the system should probably panic (in a CAPP environment at least).
That's not presently doable with the fs watch code (should I be "eeking" right
now).

I suppose in a CAPP environment if a record cannot be generate the system
should be halted, right?  Well with audit_panic the administrator has control
over that behavior.

-tim

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




More information about the Linux-audit mailing list