All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Paul Moore <pmoore@redhat.com>,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	Netfilter Developer Mailing List
	<netfilter-devel@vger.kernel.org>,
	Thomas Graf <tgraf@infradead.org>
Subject: Re: AUDIT_NETFILTER_PKT message format
Date: Mon, 13 Feb 2017 12:57:38 -0500	[thread overview]
Message-ID: <3926301.2G9jBBrVEf@x2> (raw)
In-Reply-To: <20170210225445.GS26850@madcap2.tricolour.ca>

On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
> On 2017-02-10 17:39, Steve Grubb wrote:
> > > The alternatives that I currently see are to drop packets for which
> > > there is no local process ownership, or to leave the ownership fields
> > > unset.> 
>
> > What ownership fields are we talking about?
> 
> The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> terminology.  What technical term is there for the collection of subject
> identifiers?

Subject attributes.

 
> > > > I don't think audit should worry about spoofing. Yes it can be done,
> > > > but we should accurately record what was presented to the system.
> > > > Other tools can be employed to watch for arp spoofing and source routed
> > > > packets. Its a bigger problem than just the audit logs.
> > > 
> > > I find this statement a bit surprising given we're trying to find out
> > > who's doing what where.
> > 
> > We're just recording what's presented to the system that meets the rules
> > programmed in.
> 
> I don't quite understand.  Are you saying only display the fields that
> were specifically used in the netfilter rule to trigger the target that
> records a packet?

No. I'm saying we shouldn't do any processing to figure out if we have a 
spoofed or source routed packet. There are other tools that do that kind of 
thing.


> I don't think that's what you want and it isn't easy
> to get without being more invasive in netfilter and swinging fields.
> I'd record the MAC header since it is part of the packet that tells us
> where it came from and where it's going.

Do we really need the MAC header for every event? I really don't think so.

-Steve

  reply	other threads:[~2017-02-13 17:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17  5:25 AUDIT_NETFILTER_PKT message format Richard Guy Briggs
2017-01-17 13:55 ` Steve Grubb
2017-01-17 16:12   ` Richard Guy Briggs
2017-01-17 16:29     ` Richard Guy Briggs
2017-01-17 18:35       ` Steve Grubb
2017-01-17 20:17     ` Paul Moore
2017-01-18  2:34       ` Richard Guy Briggs
2017-01-18  5:39         ` Richard Guy Briggs
2017-01-18 12:32           ` Paul Moore
2017-01-18 14:52             ` Steve Grubb
2017-01-18 15:15             ` Richard Guy Briggs
2017-01-18 23:35               ` Paul Moore
2017-01-20 14:49                 ` Steve Grubb
2017-01-20 20:37                   ` Paul Moore
2017-01-21 11:27                     ` Patrick PIGNOL
2017-01-21 17:37                       ` Paul Moore
2017-01-21 19:12                         ` Patrick PIGNOL
2017-01-23  4:49                           ` Richard Guy Briggs
2017-02-07 20:52                   ` Richard Guy Briggs
2017-02-08  3:56                     ` Paul Moore
2017-02-08 16:30                       ` Steve Grubb
2017-02-08 23:09                         ` Paul Moore
2017-02-09 10:56                           ` Pablo Neira Ayuso
2017-02-09 16:31                             ` Paul Moore
2017-02-09 23:49                           ` Richard Guy Briggs
2017-02-10  0:09                             ` Steve Grubb
2017-02-10  1:12                               ` Richard Guy Briggs
2017-02-10 22:39                                 ` Steve Grubb
2017-02-10 22:54                                   ` Richard Guy Briggs
2017-02-13 17:57                                     ` Steve Grubb [this message]
2017-02-13 20:50                                       ` Richard Guy Briggs
2017-02-13 23:50                                         ` Paul Moore
2017-02-14  0:24                                           ` Richard Guy Briggs
2017-02-14 21:06                                             ` Paul Moore
2017-02-16 22:41                                               ` Richard Guy Briggs
2017-02-16  0:32                                             ` Paul Moore
2017-02-16 22:36                                               ` Richard Guy Briggs
2017-02-17  1:57                                                 ` Paul Moore
2017-02-17  2:24                                                   ` Richard Guy Briggs
2017-02-17 23:04                                                 ` Paul Moore
2017-02-26 19:09                                             ` Richard Guy Briggs
2017-02-14 21:31                                         ` Steve Grubb
2017-02-16 21:24                                           ` Richard Guy Briggs

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=3926301.2G9jBBrVEf@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=pmoore@redhat.com \
    --cc=rgb@redhat.com \
    --cc=tgraf@infradead.org \
    /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.