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

[Timothy R. Chavez]

On Thursday 28 July 2005 11:28, Steve Grubb wrote:
> 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.

How does it "retry"?  If you do "mkdir /tmp/foo" and "foo" is being watched 
and we failed to allocate the memory to place on the audit context, "foo" gets
created and no record is generated.  This is my understanding at least (just
looking at the audit_notify_watch/auditfs_attach_wdata code).

-tim

> 
> > I suppose in a CAPP environment if a record cannot be generate the system
> > should be halted, right? 
> 
> Or the action prevented.
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 
>