[PATCH] context based audit filtering (take 3)

[Steve Grubb]

On Friday 24 February 2006 08:32, Stephen Smalley wrote:
> > > Should this be a printk or an audit_log call?
> >
> > Steve G had suggested syslogging it, so I went with the printk.  What
> > would be more noticeable?

Yes I did. The reasoning is that the rule is still there and waiting to become 
valid. I believe there was also some conversation about making a retry 
whenever policy was reloaded. So, in effect, I think this is something worthy 
of a syslog and not an audit event. I think it falls into the same category 
as doing an audit on an inode that doesn't exist.

> Anything user-triggerable should likely be using audit_log.

Its not really user triggerable. You have to be capable of loading audit 
rules....which is an auditable event.

> Internal kernel errors reflecting a bug within the kernel might still use
> printk(KERN_ERR...).

> But I think we want to migrate SELinux and audit over to using audit_log
> whenever possible, only using printk as the fallback for things like
> audit_panic, no audit daemon, etc. 

This should be the current state right now. If we have a place where something 
auditable does not create an event, please point it out.

-Steve