Clarification Around File System Auditing

Amjad Gabbar amjadgabbar11 at gmail.com
Tue Feb 14 20:55:58 UTC 2023


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.

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?



On Tue, Feb 14, 2023 at 8:29 AM Steve Grubb <sgrubb at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20230214/84bb3d37/attachment.htm>


More information about the Linux-audit mailing list