From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: 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: Tue, 17 Jan 2017 08:55:23 -0500 [thread overview]
Message-ID: <3051394.ngqbNXneNL@x2> (raw)
In-Reply-To: <20170117052551.GQ3087@madcap2.tricolour.ca>
On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> event messages and it is not quite as straightforward as I had expected.
>
> It is being tracked here:
> https://github.com/linux-audit/audit-kernel/issues/11
> and refers to a previous posting from Mr. Dash Four from four years ago
> to which there was no reply.
>
> The example given in the tracker above for "frag=" is fairly
> straightforward, but digging more, there are a number of others that are
> not quite so obvious.
>
> How many different combinations of fields is acceptable? Can we create
> new message types for each one, or is there a preferred way to indicate
> which sub-type it is other than implicit from the arguments given?
That would be preferential to swinging fields in and out. But we also don't
want to add too many new types. If two protocols look almost identical, I'd
try to coerce them to be the same. If adding 2 new types solves the problem
just do it. If it takes 10, then maybe we should understand why.
> Others that are straightforward:
> - The first "truncated=" gets pulled in with "0".
>
> - "mark=" gets pulled in with "0".
>
> Ones that are not so straightforward:
> - "secmark" depends on a kernel config setting, so should it always be
> present but "(none)" if that kernel feature is compiled out?
If this is selinux related, I'd treat it the same way that we do subj
everywhere else.
> - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
> to "(none)" to indicate that type isn't present.
"(none)" is for character fields that have nothing. Typically we set -1 for
numeric fields that are unset. If numbers are expected, its going to get the
strtol() treatment and "(none)" will cause a conversion error.
> - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> adds "ipid=", which would be set to "(none)" for ip6.
That is numeric. -1?
-Steve
> - audit_proto() pulls in "truncated=" again, then either "sport=" and
> "dport=" OR "icmptype=" and "icmpcode=".
>
> If all fields are pulled in, we end up adding 10 fields beyond a
> standard well-formed packet, and 15 beyond a truncated packet.
>
> Note: In the cases of "mark" and "secmark" both are unions. In the case of
> "mark", I don't see a problem since it isn't conditionally compiled out
> and won't be mis-interpreted. In the case of "secmark=", it could be
> mis-interpreted as offload_fwd_mark if that field is even compiled in,
> but that would be addressed in the compiler directive...
>
>
> One last question: Does anyone have a test suite that can generate any
> or all of these types of packets?
>
>
> Thanks!
>
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
next prev parent reply other threads:[~2017-01-17 13:55 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 [this message]
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
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=3051394.ngqbNXneNL@x2 \
--to=sgrubb@redhat.com \
--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).