On 16/05/16, Steve Grubb wrote:
On Sunday, May 15, 2016 04:38:27 PM Richard Guy Briggs wrote:
> Hi Steve,
>
> Can you confirm that the exclude filter action parameter is ignored?
The exclude filter was supposed to do only 1 thing, delete events. It was
needed to create a pure CAPP system back in the lspp days. There are things
like selinux which sends events whether you wanted them or not. For a pure
CAPP system you just tell it the msgtype of selinux events and then they are
gone. People found other uses later like getting rid of cron job pam messages.
But its always been used to remove events rather than trigger them.
Fine. Can we put something in the manpage to clarify that
"exclude,never" won't do what people might think, which might be to
override some other rule on a different list? Something like "The
exclude list ignores the action, and is treated as "always", or block
the never option entirely either in userspace or in the kernel. I
realize this latter option could be contentious since some might
interpret that as "breaking userspace".
> I can't find any evidence in the kernel or in userspace that
the action
> value is actually honoured. In fact, looking at the manpage for
> auditctl(8), the wording of the action contradicts the intuitive meaning
> of that filter name. And as a matter of fact, I find discussion of it
> here:
>
https://www.redhat.com/archives/linux-audit/2005-October/msg00020.html
>
>
> In auditctl, setopt() calls audit_rule_setup() which calls lookup_filter()
> and lookup_action(), then calls audit_rule_fieldpair_data() none of which
> check when parsing the AUDIT_MSGTYPE field.
>
> During rule addition, in kernel/auditfilter.c:audit_rule_change() and
> callees AUDIT_FILTER_TYPE is never checked for either action but simply
> copied.
>
> When called from audit_log_start() in
> kernel/auditfilter.c:audit_filter_type(), the state is never checked, so
> either AUDIT_NEVER or AUDIT_ALWAYS actions gives the same result which
> is to ignore that message type.
Which should delete the event from being emitted.
Yes, that is what I understand it does after reading the code carefully.
I'm saying that the rule statement syntax is non-intuitive.
-Steve
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635