* Clarification Around File System Auditing @ 2023-02-13 21:24 Amjad Gabbar 2023-02-14 14:29 ` Steve Grubb 0 siblings, 1 reply; 7+ messages in thread From: Amjad Gabbar @ 2023-02-13 21:24 UTC (permalink / raw) To: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-02-13 21:24 Clarification Around File System Auditing Amjad Gabbar @ 2023-02-14 14:29 ` Steve Grubb 2023-02-14 20:55 ` Amjad Gabbar 0 siblings, 1 reply; 7+ messages in thread From: Steve Grubb @ 2023-02-14 14:29 UTC (permalink / raw) To: linux-audit; +Cc: Amjad Gabbar 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-02-14 14:29 ` Steve Grubb @ 2023-02-14 20:55 ` Amjad Gabbar 2023-02-17 21:50 ` Steve Grubb 0 siblings, 1 reply; 7+ messages in thread From: Amjad Gabbar @ 2023-02-14 20:55 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-02-14 20:55 ` Amjad Gabbar @ 2023-02-17 21:50 ` Steve Grubb 2023-03-10 21:54 ` Richard Guy Briggs 0 siblings, 1 reply; 7+ messages in thread From: Steve Grubb @ 2023-02-17 21:50 UTC (permalink / raw) To: Amjad Gabbar; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-02-17 21:50 ` Steve Grubb @ 2023-03-10 21:54 ` Richard Guy Briggs 2023-03-15 20:29 ` Amjad Gabbar 0 siblings, 1 reply; 7+ messages in thread From: Richard Guy Briggs @ 2023-03-10 21:54 UTC (permalink / raw) To: Steve Grubb; +Cc: Amjad Gabbar, linux-audit 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-03-10 21:54 ` Richard Guy Briggs @ 2023-03-15 20:29 ` Amjad Gabbar 2023-03-16 18:58 ` Amjad Gabbar 0 siblings, 1 reply; 7+ messages in thread From: Amjad Gabbar @ 2023-03-15 20:29 UTC (permalink / raw) To: Richard Guy Briggs; +Cc: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Clarification Around File System Auditing 2023-03-15 20:29 ` Amjad Gabbar @ 2023-03-16 18:58 ` Amjad Gabbar 0 siblings, 0 replies; 7+ messages in thread From: Amjad Gabbar @ 2023-03-16 18:58 UTC (permalink / raw) To: Richard Guy Briggs; +Cc: linux-audit [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-03-17 15:27 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-13 21:24 Clarification Around File System Auditing Amjad Gabbar 2023-02-14 14:29 ` Steve Grubb 2023-02-14 20:55 ` Amjad Gabbar 2023-02-17 21:50 ` Steve Grubb 2023-03-10 21:54 ` Richard Guy Briggs 2023-03-15 20:29 ` Amjad Gabbar 2023-03-16 18:58 ` Amjad Gabbar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).