Re: [RFC PATCH] audit: normalize NETFILTER_PKT
On Tue, Jan 31, 2017 at 2:44 PM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2017-01-31 17:13, Steve Grubb wrote:
...
> I was curious about something. Auparse is trying to interpret
the
> icmptype field for every event. This is not good. Which fields are
> valid for each kind of packet? Are there fields valid for all packets?
> Is the icmptype/code the only ones that don't apply in all cases?
Ok, this is important to know... You sound surprised. So if that field
isn't valid for all cases of that event, then the event should be split
or the "unset" value should be used as a hint to ignore it.
This was the point of my earlier posting:
https://www.redhat.com/archives/linux-audit/2017-January/msg00074.html
There are still a number of questions from that thread that had no
reply. Answering those questions would help inform this discussion, so
if you could answer some of those questions in that first thread, I'd
have a better chance of understanding what are the limitations of the
parser and design/work around them.
There is no packet for which all fields are valid. This is why using
"unset" values in those fields was suggested, seemed to be accepted in
discussion, and implemented.
...
Swinging fields in and out makes it very handy to use one message
type
for all of them and can save precious disk bandwidth, but the point was
to normalize these messages. Is that still realistic and necessary? If
so, we're trying to find a balance between message type explosion and
disk bandwidth.
We either need to make this fine-grained, ignore fields that aren't
valid for that type, or swing fields in and out. Or maybe I have missed
something fundamental, such as the presence of subsequent fields depends
on the values of previous fields?
I'm still trying to understand what purpose this record actually
serves, and what requirements may exist. In an earlier thread
somewhere Steve mentioned some broad requirements around data
import/export, and I really wonder if the NETFILTER_PKT record
provides anything useful here when it really isn't connecting the
traffic to the sender/receiver without a lot of additional logging and
post-processing smarts. If you were interested in data import/export
I think auditing the socket syscalls would provide a much more useful
set of records in the audit log.
Considering that one of the primary motivations for the audit
subsystem is to enable compliance with various security
specifications, let's get the ones we know about listed in this thread
and then figure out how best to meet those requirements.
--
paul moore
www.paul-moore.com