All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com, Amjad Gabbar <amjadgabbar11@gmail.com>
Cc: Richard Guy Briggs <rgb@redhat.com>
Subject: Re: Sycall Rules vs Watch Rules
Date: Tue, 19 Sep 2023 19:12:14 -0400	[thread overview]
Message-ID: <8295448.T7Z3S40VBb@x2> (raw)
In-Reply-To: <CAJcJf=TQ6R4zjNPX+TQyDBxtFz+QWQWDqT3t0PEXvzp9CvJS_g@mail.gmail.com>

Hello,

On Tuesday, September 12, 2023 5:20:54 PM EDT Amjad Gabbar wrote:
> Based on this and some experiments I have been performing, I would suggest
> changing how a lot of the FileSystem rules are written and illustrated.
> Ex -
> https://github.com/linux-audit/audit-userspace/blob/master/rules/30-pci-dss
> -v31.rules#L34-L35
> 
> The rule in the repository is
> -a always,exit -F path=/etc/sudoers -F perm=wa -F
> key=10.2.2-priv-config-changes
> 
> My suggestion is to instead change the rule based on the permissions
> defined. The above rule would change to the following based on the kernel
> being used.
> -a always,exit -S <list of syscalls in audit_write.h and audit_read.h
> +open,openat> -F path=/etc/sudoers -F perm=wa -F
> key=10.2.2-priv-config-changes

That should be exactly what the kernel does with the perm fields. The perm 
fields select the right system calls that should be reported on.
 
> This is higher performance because we are limiting the syscalls instead of
> making use of -S all which has more paths of evaluation for each and every
> syscall.
> 
> Same thing for watches. Watches are inherently -S all rules which are very
> performance intensive.
> https://github.com/linux-audit/audit-userspace/blob/1482cec74f2d9472f81dd4f
> 0533484bd0c26decd/lib/libaudit.c#L805

There should be no difference in performance between watches and syscall 
based file auditing.

> Ideally we should limit the syscalls based on the permissions being used.
> 
> I have implemented the same in my environment rules and have noticed a
> massive performance difference with no difference in the events being
> logged since we anyways filter eventually based on the permissions.
> 
> Let me know what you all think.

I'm looking into this more. I see a 1 line change that I am testing.

-Steve

> On Wed, Sep 6, 2023 at 2:58 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2023-09-06 10:56, Amjad Gabbar wrote:
> > > Hi,
> > > 
> > > I have done some analysis and digging into how both the watch rules and
> > > syscall rules are translated.
> > > 
> > > From my understanding, in terms of logging, both the below rules are
> > > similar. There is no difference in either of the rules.
> > > 
> > > 1. -w /etc -p wa -k ETC_WATCH
> > 
> > They are similar in this case.
> > -w behaves differently depending on the existance of the watched entity
> > and the presence of a trailing "/".  This is why the form above is
> > deprecated.
> > 
> > > 2. -a always,exit -F arch=b64 -S <all syscalls part of the write and
> > > attr
> > > classes> -F dir=/etc  -F perm=wa -k ETC_WATCH
> > > 
> > > The write and attr classes consist of syscalls in
> > > “include/asm-generic/audit_*.h“.
> > > 
> > >  The perm flag is needed in the second case for including open/openat
> > > 
> > > syscalls which are not a part of the write and attr syscall list.
> > > 
> > > I'd like to verify if what I mentioned earlier is accurate, and I have
> > > an
> > > additional point but depends on whether this is accurate.
> > > 
> > > Ali
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Sr. S/W Engineer, Kernel Security, Base Operating Systems
> > Remote, Ottawa, Red Hat Canada
> > Upstream IRC: SunRaycer
> > Voice: +1.613.860 2354 SMS: +1.613.518.6570




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

  parent reply	other threads:[~2023-09-20  0:26 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 [this message]
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
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=8295448.T7Z3S40VBb@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.