Re: Clarification Around File System Auditing

[Amjad Gabbar]

Also, we would need to have a separate rule for open and openat family with
something like

-S open,openat -F dir=/etc -F perm=wa -k ETC_WATCH.

So 2 syscall rules instead of 1 watch rule but we replace -S all with
specific syscalls.

Or we could combine all these open,openat,write family syscalls into a
single syscall rule but with the permissions flag.

On Wed, Mar 15, 2023 at 3:29 PM Amjad Gabbar 
wrote:

> YupI was able to find the dummy check you are referring to and the
> audit_reset_context() that is called next(which immediately exits in case
> of dummy).
> Thanks for the help folkshave a much better understanding of how the
> audit context is allocated on enabling syscall auditing and the whole flow
> post that.
>
> Had just 1 question wrt watches. IIUC, for watch rules we evaluate all
> syscalls (Snippet from audit-userspace:
> https://github.com/linux-audit/audit-userspace/blob/1482cec74f2d9472f81dd4f0533484bd0c26decd/lib/libaudit.c#L805
> ).
> But based on the permissions in the rule, we evaluate if the syscall
> belongs to a specific Audit Class using audit_match_class() and only log if
> the syscalls match/ are part of the class. This also explains why I see
> audit_filter_rules() called for watches even if the syscall being performed
> is not at all related to file system auditing.
>
>
>1. I was wondering why do we not automatically identify if the syscall
>is of interest or not in audit_in_mask() itself based on the rule
>permissions of the watch? In this way we would avoid the additional
>overhead of each syscall going into audit_filter_rules() and then
>evaluating on the AUDIT_PERM case as well.
>
>
> Currently a watch rule for "wa" permissions for /etc is similar to :
> -a always,exit -F arch=b64 -S all -F dir=/etc -F perm=wa -k ETC_WATCH
>
> We only log if the syscall is part of the WRITE and ATTR permissions set.
> Instead what I was suggesting was something like this:
>
> -a always,exit -F arch=b64 -S  classes> -F dir=/etc  -k ETC_WATCH
>
> Please correct me if my understanding in any of the above is incorrect.
>
> On Fri, Mar 10, 2023 at 3:54 PM Richard Guy Briggs  wrote:
>
>> On 2023-02-17 16:50, Steve Grubb wrote:
>> > 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.
>>
>> There is essentially an empty list check in __audit_syscall_exit() with
>> the dummy check, based on the number of syscall (or io_uring) rules in
>> place tracked in audit_n_rules.  Unfortunately, we can't bail from
>> __audit_syscall_entry() right after setting dummy because other
>> hardwired records can cancel the dummy flag.
>>
>> > -Steve
>> >
>> > > 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 l

Re: Clarification Around File System Auditing

[Amjad Gabbar]

YupI was able to find the dummy check you are referring to and the
audit_reset_context() that is called next(which immediately exits in case
of dummy).
Thanks for the help folkshave a much better understanding of how the
audit context is allocated on enabling syscall auditing and the whole flow
post that.

Had just 1 question wrt watches. IIUC, for watch rules we evaluate all
syscalls (Snippet from audit-userspace:
https://github.com/linux-audit/audit-userspace/blob/1482cec74f2d9472f81dd4f0533484bd0c26decd/lib/libaudit.c#L805
).
But based on the permissions in the rule, we evaluate if the syscall
belongs to a specific Audit Class using audit_match_class() and only log if
the syscalls match/ are part of the class. This also explains why I see
audit_filter_rules() called for watches even if the syscall being performed
is not at all related to file system auditing.


   1. I was wondering why do we not automatically identify if the syscall
   is of interest or not in audit_in_mask() itself based on the rule
   permissions of the watch? In this way we would avoid the additional
   overhead of each syscall going into audit_filter_rules() and then
   evaluating on the AUDIT_PERM case as well.


Currently a watch rule for "wa" permissions for /etc is similar to :
-a always,exit -F arch=b64 -S all -F dir=/etc -F perm=wa -k ETC_WATCH

We only log if the syscall is part of the WRITE and ATTR permissions set.
Instead what I was suggesting was something like this:

-a always,exit -F arch=b64 -S  -F dir=/etc  -k ETC_WATCH

Please correct me if my understanding in any of the above is incorrect.

On Fri, Mar 10, 2023 at 3:54 PM Richard Guy Briggs  wrote:

> On 2023-02-17 16:50, Steve Grubb wrote:
> > 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.
>
> There is essentially an empty list check in __audit_syscall_exit() with
> the dummy check, based on the number of syscall (or io_uring) rules in
> place tracked in audit_n_rules.  Unfortunately, we can't bail from
> __audit_syscall_entry() right after setting dummy because other
> hardwired records can cancel the dummy flag.
>
> > -Steve
> >
> > > 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
> > > > > <
> https://elixir.bootlin.com/linux/v

Re: Clarification Around File System Auditing

[Richard Guy Briggs]

On 2023-02-17 16:50, Steve Grubb wrote:
> 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.

There is essentially an empty list check in __audit_syscall_exit() with
the dummy check, based on the number of syscall (or io_uring) rules in
place tracked in audit_n_rules.  Unfortunately, we can't bail from
__audit_syscall_entry() right after setting dummy because other
hardwired records can cancel the dummy flag.

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

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, In

Re: Clarification Around File System Auditing

[Steve Grubb]

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

Clarification Around File System Auditing

[Amjad Gabbar]

Hi Everyone,

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?

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?

Please correct any wrong assumption I may have as well.

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