Hello,
On Tuesday, February 14, 2023 3:55:58 PM EST Amjad Gabbar wrote:
Thanks for the reply.
I was trying to evaluate the same via Flamegraphs and what I noticed was
that :
1. Despite deleting all rules (auditctl -D), there were still calls to
audit_filter_syscall() on each syscall. I assume this is because syscall
auditing is enabled and despite no rules, there still will be some
performance impact and calls to syscall filtering functions on each
syscall.
Yes.
2. For a single watch rule as well without any syscall rules, I could
see
calls to audit_filter_syscall() followed by audit_filter_rules() for
unrelated syscalls such as futex() and recvmsg() - not present in
include/asm-generic/audit_*.h
Why would these functions be called for a single watch rule for syscalls
unrelated to the permissions?
If auditing is enabled, it will go into the syscall filter for *any* syscall.
It will go into __audit_syscall_exit for every syscall. If there is an audit
context, it will go into audit_filter_syscall. The documentation in the
comments above these functions is informative.
My guess is that this code path might benefit from adding a list_empty check.
A long time ago, I think we kept a variable that denoted if there were any
rules and short-circuited if none.
-Steve
On Tue, Feb 14, 2023 at 8:29 AM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> Hello,
>
> On Monday, February 13, 2023 4:24:02 PM EST Amjad Gabbar wrote:
> > I wanted some help in better understanding the workflow of file system
> > auditing(watch rules) vs Syscall Auditing(syscall rules). I know in
>
> general
>
> > file system auditing does not have the same performance impact as
> > syscall
> > auditing, even though both make use of syscall exits for their
>
> evaluation.
>
> > From the manpage - "Unlike most syscall auditing rules, watches do not
> > impact performance based on the number of rules sent to the kernel."
> >
> > From a previous thread, I found this excerpt regarding file watch rules
>
> vs
>
> > sycall rules -
> >
> > "The reason it doesn't have performance impact like normal syscall
> > rules
>
> is
>
> > because it gets moved to a list that is not evaluated every syscall. A
> > normal syscall rule will get evaluated for every syscall because it has
>
> to
>
> > see if the syscall number is of interest and then it checks the next
> > rule."
> >
> > Based on this I had a couple of questions:
> >
> > For normal syscall rules, the evaluation happens as
> > __audit_syscall_exit
> > <
https://elixir.bootlin.com/linux/v6.1.10/C/ident/__audit_syscall_exit>
> > calls audit_filter_syscall
> > (
https://elixir.bootlin.com/linux/v6.1.10/source/kernel/auditsc.c#L841)
> >
> > Here, we check if the syscall is of interest or not in the
> > audit_in_mask
> > <
https://elixir.bootlin.com/linux/v6.1.10/C/ident/audit_in_mask>
>
> function.
>
> > Only if the syscall is of interest do we proceed with examining the
> > task
> > and return on the first rule match.
> >
> > 1. What is the process or code path for watch rules?
> > audit_filter_syscall
> > <
https://elixir.bootlin.com/linux/v6.1.10/C/ident/audit_filter_syscall>
>
> is
>
> > called for watch rules as well. Then how is it that these are not
> > called
> > for every syscall? Could you point me to the code where the evaluation
> > happens only once?
>
> There is a file, kernel/audit_watch.c, that implements the interface
> between
> audit and fsnotify. You would want to learn how fsnotify works to
> understand
> how it avoids the syscall filter.
>
> > 2. Also, do file watches only involve the open system call family
> > (open,
> > openat etc). The man page implies the same, so just wanted to confirm.
> >
> > I assume -w /etc -p wa is the same as -a always,exit -S open -S openat
> > -F
> > dir=/etc?
>
> It depends on the flag passed for perm as to what syscall it wants. See:
>
> include/asm-generic/audit_*.h
>
> -Steve