All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Amjad Gabbar <amjadgabbar11@gmail.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: Sycall Rules vs Watch Rules
Date: Thu, 28 Sep 2023 11:53:26 -0400	[thread overview]
Message-ID: <4866749.31r3eYUQgx@x2> (raw)
In-Reply-To: <CAJcJf=RKAqp0PPQ2EmOZ5jJ6KGZ4rAvmabdDsg+MvkbmcomChA@mail.gmail.com>

On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > The best solution would be a kernel modification so that there are no
> > mismatched lists.
>
> I agree as well....This would be the cleanest solution. This would also
> solve the userspace problem of maintaining different lists which can get
> out of hand fairly quickly.

After looking into this, a kernel patch would also not work well. It has to 
be arch specific
 
> > I guess we can warn on that to rewrite in syscall notation.
> 
> We certainly should. I think the user should know that there is a
> performance cost associated with watches and we should explicitly mention
> how it can be optimized in the manpages also. The reason being I am pretty
> sure, numerous users/repos still do make use of the -w notation and we do
> want to let them know the issue here. We also need to make quite a few
> changes to the manpages also regarding this. Because, initially even I was
> very confused when reading the man pages and seeing the actual
> implementation of and results were not quite in sync.

I have made the changes to the master and audit-3.1-maint branches. Please 
everyone concerned give them tests. The short of it is that if you use the '-
w' notation for watches, it will remain the same and slower. If you use the 
syscall notation without "-F arch", you will get a warning that it cannot be 
optimized without adding "-Farch". If you add "-F arch", you will possibly 
need one for both arches which means doubling the rules. If you do not want 
to double the rules, you might place a syscall rule for any 32 system call 
(21-no32bit.rules). Or you can leave it as is and not care. The sample rules 
and all man pages have been updated.

Please, let me know if this works out better.

-Steve


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


  reply	other threads:[~2023-09-28 16:06 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
2023-09-20 23:33           ` Steve Grubb
2023-09-21 20:02             ` Amjad Gabbar
2023-09-28 15:53               ` Steve Grubb [this message]
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=4866749.31r3eYUQgx@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 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.