Re: [PATCH] support for context based audit filtering
On Fri, Mar 10, 2006 at 05:03:36PM -0500, Steve Grubb wrote:
On Friday 10 March 2006 16:57, Amy Griffis wrote:
> You may want to audit_log a message indicating that the audit rules
> were updated due to policy reload. ?And in the case when you remove a
> rule because you couldn't update it, you might want to log that too.
Do we really need to audit_log that? I would think that syslog is
enough.
Syslog is not a good solution when the audit log is available. The
reason to audit_log is to maintain the sequence of events, otherwise
it's necessary (and perhaps impossible) to piece together the audit
log and syslog to figure out in what order things happened.
We already have an event that a policy load occurred, can it
be assumed that all these were updated?
Yes, that may be fine since the part of the rule that's being changed
is never indicated as part of other records (the string representation
is all you see).
However, in the case that a rule couldn't be properly updated and we
did not have an audit failure panic, I think the audit log should show
that a rule was removed.
We do not do audit_log for other things that may or may not exist.
For example, what if you put a rule in for uid=5000 when you meant
500. The kernel does not say anything.
This is a little different from your example in that the kernel is
actually modifying what the user specified. But as I said above, the
extra verification in the successful case is probably meaningless.
Amy