Clarification Around File System Auditing

Clarification Around File System Auditing

[Amjad Gabbar]

[-- Attachment #1.1: Type: text/plain, Size: 1997 bytes --]

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

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

[-- Attachment #1.2: Type: text/html, Size: 4217 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

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


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

Re: Clarification Around File System Auditing

[Amjad Gabbar]

[-- Attachment #1.1: Type: text/plain, Size: 3298 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4653 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

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




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

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

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Clarification Around File System Auditing

[Amjad Gabbar]

[-- Attachment #1.1: Type: text/plain, Size: 7291 bytes --]

Yup....I 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 folks....have 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 <all syscalls part of the write and attr
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 <rgb@redhat.com> 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 <sgrubb@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
> >
> >
> >
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://listman.redhat.com/mailman/listinfo/linux-audit
> >
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
>
>

[-- Attachment #1.2: Type: text/html, Size: 9963 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

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

Re: Clarification Around File System Auditing

[Amjad Gabbar]

[-- Attachment #1.1: Type: text/plain, Size: 7987 bytes --]

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 <amjadgabbar11@gmail.com>
wrote:

> Yup....I 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 folks....have 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 <all syscalls part of the write and attr
> 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 <rgb@redhat.com> 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 <sgrubb@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
>> >
>> >
>> >
>> >
>> > --
>> > Linux-audit mailing list
>> > Linux-audit@redhat.com
>> > https://listman.redhat.com/mailman/listinfo/linux-audit
>> >
>>
>> - RGB
>>
>> --
>> Richard Guy Briggs <rgb@redhat.com>
>> Sr. S/W Engineer, Kernel Security, Base Operating Systems
>> Remote, Ottawa, Red Hat Canada
>> IRC: rgb, SunRaycer
>> Voice: +1.647.777.2635, Internal: (81) 32635
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 10846 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

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