Re: Clarification Around File System Auditing

[Amjad Gabbar]

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  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
> > 
> > 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
> > 
> 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
> > 
> 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
>
>
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] tests/filter_exclude: euid filtering now possible in exclude filter

[Paul Moore]

On Tue, Feb 14, 2023 at 2:23 PM Paul Moore  wrote:
>
> Starting with Steve's audit userspace v3.1, an euid exclude filter no
> longer results in an error.  Adjust the test accordingly.
>
> Signed-off-by: Paul Moore 
> ---
>  tests/filter_exclude/test | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

As we are nearing the next upstream kernel release I'm going to merge
this right now so the tests continue to run clear (making it easier to
catch other regressions quickly), but if anyone has any concerns over
this patch please still voice them and I'll be sure to fix them up.

> diff --git a/tests/filter_exclude/test b/tests/filter_exclude/test
> index 7a8e3fb..248fc54 100755
> --- a/tests/filter_exclude/test
> +++ b/tests/filter_exclude/test
> @@ -103,7 +103,7 @@ $result = system("auditctl -a exclude,always -F 
> ppid=$ppid >/dev/null 2>&1");
>  ok( $result ne 0 );
>  system("auditctl -d exclude,always -F ppid=$ppid >/dev/null 2>&1");
>  $result = system("auditctl -a exclude,always -F euid=$euid >/dev/null 2>&1");
> -ok( $result ne 0 );
> +ok( $result, 0 );
>  system("auditctl -d exclude,always -F euid=$euid >/dev/null 2>&1");
>  $result =
>system("auditctl -a exclude,always -F obj_user=$obj_user >/dev/null 2>&1");
> --
> 2.39.1

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

[PATCH] tests/filter_exclude: euid filtering now possible in exclude filter

[Paul Moore]

Starting with Steve's audit userspace v3.1, an euid exclude filter no
longer results in an error.  Adjust the test accordingly.

Signed-off-by: Paul Moore 
---
 tests/filter_exclude/test | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/filter_exclude/test b/tests/filter_exclude/test
index 7a8e3fb..248fc54 100755
--- a/tests/filter_exclude/test
+++ b/tests/filter_exclude/test
@@ -103,7 +103,7 @@ $result = system("auditctl -a exclude,always -F ppid=$ppid 
>/dev/null 2>&1");
 ok( $result ne 0 );
 system("auditctl -d exclude,always -F ppid=$ppid >/dev/null 2>&1");
 $result = system("auditctl -a exclude,always -F euid=$euid >/dev/null 2>&1");
-ok( $result ne 0 );
+ok( $result, 0 );
 system("auditctl -d exclude,always -F euid=$euid >/dev/null 2>&1");
 $result =
   system("auditctl -a exclude,always -F obj_user=$obj_user >/dev/null 2>&1");
-- 
2.39.1

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Clarification Around File System Auditing

[Steve Grubb]

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
> 
> 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
>  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
>  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


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit