From: Steve Grubb <sgrubb@redhat.com>
To: Amjad Gabbar <amjadgabbar11@gmail.com>, linux-audit@redhat.com
Cc: Richard Guy Briggs <rgb@redhat.com>
Subject: Re: Sycall Rules vs Watch Rules
Date: Wed, 20 Sep 2023 14:45:26 -0400 [thread overview]
Message-ID: <2334800.ElGaqSPkdT@x2> (raw)
In-Reply-To: <CAJcJf=SJxd3bnu2Pi4Ps5fL8NUowQrvuVn+VgrBK5bY0pUdbAg@mail.gmail.com>
On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote:
> > The perm fields select the right system calls
> > that should be reported on.
>
> That is accurate from a functional perspective. There is no change in the
> events logged. But there is a difference in performance. This is most
> evident for syscalls not part of the perm fields.
<snip>
> If we look at the performance numbers for the file rules as is, the
> auditing percentage is about 14%.
>
> Now if we were to just add the specific syscalls that the perm fields
> filter on in the rules file, the auditing percentage would drop to around
> 2%.
I think I am mis-remembering something, or there was a change way back in the
beginning. The plan was that we could optimize access by letting the kernel
pick the relevant syscalls based on the permissions. User space would just
define the permissions and the kernel would make it so.
But there were several redesigns of the file auditing. I looked back as far as
the 3.1 kernel and it always follows lookup the syscall, if it's relevant,
then check the rest of the fields in the rule. This eventually checks the set
of syscalls selected by the perms.
The way that it should have worked is when perms is given, throw away any
syscalls and set the mask based on the perms selected. That would have been
optimal and it was what Al Viro and I talked about long ago. However, it went
through several redesigns.
The problem now is that user space has no list of syscalls that match each
permission. And then, there's no good way to sync based on mixing and
matching kernels and user space. The kernel may have an updated syscall list
user space doesn't know about and vice versa.
I think you are on to something important. But I am surprised my concept of
how it works doesn't match the implementation. (Al Viro did the original
implementation way back around 2006/7.) The best solution would be a kernel
modification so that there are no mismatched lists. A suboptimal solution
would be to maintain 2 lists and hope they don't change. Which by the way, I
think the kernel lists are outdated again. (Syscalls keep getting added -
quotactl_fd for example)
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2023-09-20 18:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 15:56 Sycall Rules vs Watch Rules Amjad Gabbar
2023-09-06 19:58 ` Richard Guy Briggs
2023-09-12 21:20 ` Amjad Gabbar
2023-09-15 6:00 ` Amjad Gabbar
2023-09-19 23:12 ` Steve Grubb
2023-09-20 0:26 ` Amjad Gabbar
2023-09-20 18:45 ` Steve Grubb [this message]
2023-09-20 23:33 ` Steve Grubb
2023-09-21 20:02 ` Amjad Gabbar
2023-09-28 15:53 ` Steve Grubb
2023-09-28 16:30 ` Steve Grubb
2023-09-29 16:39 ` Amjad Gabbar
2023-10-08 4:46 ` 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=2334800.ElGaqSPkdT@x2 \
--to=sgrubb@redhat.com \
--cc=amjadgabbar11@gmail.com \
--cc=linux-audit@redhat.com \
--cc=rgb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox