All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: fw@strlen.de, LKML <linux-kernel@vger.kernel.org>,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	netfilter-devel@vger.kernel.org, ebiederm@xmission.com,
	twoerner@redhat.com, Eric Paris <eparis@parisplace.org>,
	tgraf@infradead.org
Subject: Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister
Date: Fri, 08 May 2020 14:23:17 -0400	[thread overview]
Message-ID: <1894903.vQEQaK82eK@x2> (raw)
In-Reply-To: <20200506224233.najv6ltb5gzcicqb@madcap2.tricolour.ca>

On Wednesday, May 6, 2020 6:42:33 PM EDT Richard Guy Briggs wrote:
> > > > We can't be adding deleting fields based on how its triggered. If
> > > > they are unset, that is fine. The main issue is they have to behave
> > > > the same.
> > > 
> > > I don't think the intent was to have fields swing in and out depending
> > > on trigger.  The idea is to potentially permanently not include them in
> > > this record type only.  The justification is that where they aren't
> > > needed for the kernel trigger situation it made sense to delete them
> > > because if it is a user context event it will be accompanied by a
> > > syscall record that already has that information and there would be no
> > > sense in duplicating it.
> > 
> > We should not be adding syscall records to anything that does not result
> > from a syscall rule triggering the event. Its very wasteful. More
> > wasteful than just adding the necessary fields.
> 
> So what you are saying is you want all the fields that are being
> proposed to be added to this record?

Yes.

> If the records are all from one event, they all should all have the same
> timestamp/serial number so that the records are kept together and not
> mistaken for multiple events.

But NETFILTER_CFG is a simple event known to have only 1 record.

> One reason for having information in seperate records is to be able to
> filter them either in kernel or in userspace if you don't need certain
> records.

We can't filter out SYSCALL.

-Steve


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


WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, omosnace@redhat.com,
	fw@strlen.de, twoerner@redhat.com,
	Eric Paris <eparis@parisplace.org>,
	ebiederm@xmission.com, tgraf@infradead.org
Subject: Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister
Date: Fri, 08 May 2020 14:23:17 -0400	[thread overview]
Message-ID: <1894903.vQEQaK82eK@x2> (raw)
In-Reply-To: <20200506224233.najv6ltb5gzcicqb@madcap2.tricolour.ca>

On Wednesday, May 6, 2020 6:42:33 PM EDT Richard Guy Briggs wrote:
> > > > We can't be adding deleting fields based on how its triggered. If
> > > > they are unset, that is fine. The main issue is they have to behave
> > > > the same.
> > > 
> > > I don't think the intent was to have fields swing in and out depending
> > > on trigger.  The idea is to potentially permanently not include them in
> > > this record type only.  The justification is that where they aren't
> > > needed for the kernel trigger situation it made sense to delete them
> > > because if it is a user context event it will be accompanied by a
> > > syscall record that already has that information and there would be no
> > > sense in duplicating it.
> > 
> > We should not be adding syscall records to anything that does not result
> > from a syscall rule triggering the event. Its very wasteful. More
> > wasteful than just adding the necessary fields.
> 
> So what you are saying is you want all the fields that are being
> proposed to be added to this record?

Yes.

> If the records are all from one event, they all should all have the same
> timestamp/serial number so that the records are kept together and not
> mistaken for multiple events.

But NETFILTER_CFG is a simple event known to have only 1 record.

> One reason for having information in seperate records is to be able to
> filter them either in kernel or in userspace if you don't need certain
> records.

We can't filter out SYSCALL.

-Steve



  parent reply	other threads:[~2020-05-08 18:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 21:39 [PATCH ghak25 v4 0/3] Address NETFILTER_CFG issues Richard Guy Briggs
2020-04-22 21:39 ` Richard Guy Briggs
2020-04-22 21:39 ` [PATCH ghak25 v4 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs
2020-04-22 21:39   ` Richard Guy Briggs
2020-04-28 22:15   ` Paul Moore
2020-04-28 22:15     ` Paul Moore
2020-04-22 21:39 ` [PATCH ghak25 v4 2/3] netfilter: add audit table unregister actions Richard Guy Briggs
2020-04-22 21:39   ` Richard Guy Briggs
2020-04-28 22:15   ` Paul Moore
2020-04-28 22:15     ` Paul Moore
2020-04-22 21:39 ` [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Richard Guy Briggs
2020-04-22 21:39   ` Richard Guy Briggs
2020-04-28 22:25   ` Paul Moore
2020-04-28 22:25     ` Paul Moore
2020-04-29 14:31     ` Richard Guy Briggs
2020-04-29 14:31       ` Richard Guy Briggs
2020-04-29 18:47       ` Steve Grubb
2020-04-29 18:47         ` Steve Grubb
2020-04-29 21:32         ` Richard Guy Briggs
2020-04-29 21:32           ` Richard Guy Briggs
2020-05-01 16:23           ` Paul Moore
2020-05-01 16:23             ` Paul Moore
2020-05-06 21:26           ` Steve Grubb
2020-05-06 21:26             ` Steve Grubb
2020-05-06 22:42             ` Richard Guy Briggs
2020-05-06 22:42               ` Richard Guy Briggs
2020-05-08  2:45               ` Paul Moore
2020-05-08  2:45                 ` Paul Moore
2020-05-08 18:23               ` Steve Grubb [this message]
2020-05-08 18:23                 ` Steve Grubb
2020-05-17 14:15     ` Richard Guy Briggs
2020-05-17 14:15       ` Richard Guy Briggs
2020-05-17 18:25       ` Casey Schaufler
2020-05-17 21:55         ` Paul Moore
2020-05-17 21:50       ` Paul Moore
2020-05-17 21:50         ` Paul Moore
2020-05-18  0:39         ` Richard Guy Briggs
2020-05-18  0:39           ` Richard Guy Briggs
2020-05-18 14:40           ` Paul Moore
2020-05-18 14:40             ` Paul Moore

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=1894903.vQEQaK82eK@x2 \
    --to=sgrubb@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=fw@strlen.de \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rgb@redhat.com \
    --cc=tgraf@infradead.org \
    --cc=twoerner@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.