[PATCH] LSPP audit enablement: storing selinux ocontext and scontext
Steve Grubb
sgrubb at redhat.com
Thu Jul 28 16:28:13 UTC 2005
On Thursday 28 July 2005 12:12, Timothy R. Chavez wrote:
> Yeah, I'm thinking I should be calling audit_panic() instead.
I don't think so. There are many places in the kernel where failed memory
alloc results in -ENOMEM.
> 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.
This is an exceptional condition. I would be very unhappy as an admin if I had
to constantly investigate why my machine had panic'd. I would rather the
machine stay alive and have the syscall fail. The user can retry and if
memory pressure has eased - we'll get the event.
> 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).
If the syscall failed due to audit system problem, the auditable event never
occurred. They were prevented. They should retry and hopefully the memory
situation has changed.
> I suppose in a CAPP environment if a record cannot be generate the system
> should be halted, right?
Or the action prevented.
-Steve
More information about the Linux-audit
mailing list