All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Amjad Gabbar <amjadgabbar11@gmail.com>
Cc: linux-audit@redhat.com
Subject: Re: Clarification Around File System Auditing
Date: Fri, 17 Feb 2023 16:50:15 -0500	[thread overview]
Message-ID: <2289859.ElGaqSPkdT@x2> (raw)
In-Reply-To: <CAJcJf=R4KgO_LwBfqgkFRKK+zJrth=CN1wvu1wqaEupaS_q_ww@mail.gmail.com>

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


  reply	other threads:[~2023-02-17 21:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2023-03-10 21:54       ` Richard Guy Briggs
2023-03-15 20:29         ` Amjad Gabbar
2023-03-16 18:58           ` Amjad Gabbar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2289859.ElGaqSPkdT@x2 \
    --to=sgrubb@redhat.com \
    --cc=amjadgabbar11@gmail.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.