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

On Thursday, September 28, 2023 11:53:26 AM EDT Steve Grubb wrote:
> 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.

Actually, ths is the one that draws the warning to urge people to migrate.

> If you use
> the syscall notation without "-F arch", you will get a warning that it
> cannot be optimized without adding "-Farch".

Actually, you won't in order to preserve intentional behavior.

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

I should have provided an example of what this means. If you have this kind
of rule:

-w /etc/shadow -p wa -k shadow

And when applied draws a warning:

# auditctl -w /etc/shadow -p wa -k shadow
Old style watch rules are slower

It should be rewritten as

-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow

Then it looks like this when loaded:

#auditctl -l
-a always,exit -F arch=b64 -S open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2 -F path=/etc/shadow -F perm=wa -F key=shadow

And to delete  the rule, 
auditctl -d always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow

or the long way

auditctl -d always,exit -F arch=b64 -S open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2 -F path=/etc/shadow -F perm=wa -F key=shadow

Hopefully this is clearer what the change is.
 
-Steve



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


  reply	other threads:[~2023-09-28 16:49 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
2023-09-28 16:30                 ` Steve Grubb [this message]
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=3262512.44csPzL39Z@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.