Re: [PATCH] context based audit filtering (take 3)
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