From: Paul Moore <paul@paul-moore.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Florian Westphal <fw@strlen.de>,
linux-audit@redhat.com,
Netfilter Developer Mailing List
<netfilter-devel@vger.kernel.org>,
Thomas Graf <tgraf@infradead.org>
Subject: Re: [PATCH V2] audit: normalize NETFILTER_PKT
Date: Thu, 23 Feb 2017 12:14:51 -0500 [thread overview]
Message-ID: <CAHC9VhSUKTQ+mx4ha7_LRM7SaSbnK9sP5Sz7C+aFn26sB0riBQ@mail.gmail.com> (raw)
In-Reply-To: <20170223171324.GN18258@madcap2.tricolour.ca>
On Thu, Feb 23, 2017 at 12:13 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-23 12:06, Paul Moore wrote:
>> On Thu, Feb 23, 2017 at 12:04 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2017-02-23 11:57, Paul Moore wrote:
>> >> On Thu, Feb 23, 2017 at 10:51 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> >> > On 2017-02-23 06:20, Florian Westphal wrote:
>> >> >> Richard Guy Briggs <rgb@redhat.com> wrote:
>> >> >> > Simplify and eliminate flipping in and out of message fields, relying on nfmark
>> >> >> > the way we do for audit_key.
>> >> >> >
>> >> >> > +struct nfpkt_par {
>> >> >> > + int ipv;
>> >> >> > + const void *saddr;
>> >> >> > + const void *daddr;
>> >> >> > + u8 proto;
>> >> >> > +};
>> >> >>
>> >> >> This is problematic, see below for why.
>> >> >>
>> >> >> > -static void audit_ip4(struct audit_buffer *ab, struct sk_buff *skb)
>> >> >> > +static void audit_ip4(struct audit_buffer *ab, struct sk_buff *skb, struct nfpkt_par *apar)
>> >> >> > {
>> >> >> > struct iphdr _iph;
>> >> >> > const struct iphdr *ih;
>> >> >> >
>> >> >> > + apar->ipv = 4;
>> >> >> > ih = skb_header_pointer(skb, 0, sizeof(_iph), &_iph);
>> >> >> > - if (!ih) {
>> >> >> > - audit_log_format(ab, " truncated=1");
>> >> >> > + if (!ih)
>> >> >> > return;
>> >> >>
>> >> >> Removing this "truncated" has the consequence that this can later log
>> >> >> "saddr=0.0.0.0 daddr=0.0.0.0" if we return here.
>> >> >>
>> >> >> This cannot happen for ip(6)tables because ip stack discards broken l3 headers
>> >> >> before the netfilter hooks get called, but its possible with NFPROTO_BRIDGE.
>> >> >>
>> >> >> Perhaps you will need to change audit_ip4/6 to return "false" when it can't
>> >> >> get the l3 information now so we only log zero addresses when the packet
>> >> >> really did contain them.
>> >> >
>> >> > Ok, to clarify the implications, are you saying that handing a NULL
>> >> > pointer to "saddr=%pI4" will print "0.0.0.0" rather than "(none)" or "?"
>> >>
>> >> My initial reaction is that if the packet is so badly
>> >> truncated/malformed that we don't have a full IP header than we should
>> >> just refrain from logging the packet; it's too malformed/garbage to
>> >> offer any useful information and the normal packet processing should
>> >> result in the packet being discarded anyway.
>> >
>> > Which is why I wanted the ethertype, but that can be coded into the nfmark.
>>
>> If the packet is garbage (garbage without any payload in this case),
>> what does it matter? It's noise.
>
> It could be an indicator that either the logging rules or the filter
> rules need honing, or even that there is a bug in the network code.
Elaborate on this please, I still don't see how logging the ethertype
is helpful for a malformed packet.
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2017-02-23 17:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 2:50 [PATCH V2] audit: normalize NETFILTER_PKT Richard Guy Briggs
2017-02-23 5:20 ` Florian Westphal
2017-02-23 15:51 ` Richard Guy Briggs
2017-02-23 16:57 ` Paul Moore
2017-02-23 17:04 ` Richard Guy Briggs
2017-02-23 17:06 ` Paul Moore
2017-02-23 17:13 ` Richard Guy Briggs
2017-02-23 17:14 ` Paul Moore [this message]
2017-02-23 17:35 ` Richard Guy Briggs
2017-02-24 0:54 ` Paul Moore
2017-02-24 1:50 ` Florian Westphal
2017-02-23 17:06 ` Florian Westphal
2017-02-23 17:20 ` Richard Guy Briggs
2017-02-24 1:59 ` Florian Westphal
2017-02-24 5:56 ` Paul Moore
2017-02-23 17:20 ` Steve Grubb
2017-02-23 17:29 ` 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=CAHC9VhSUKTQ+mx4ha7_LRM7SaSbnK9sP5Sz7C+aFn26sB0riBQ@mail.gmail.com \
--to=paul@paul-moore.com \
--cc=fw@strlen.de \
--cc=linux-audit@redhat.com \
--cc=netfilter-devel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).