Re: AUDIT_NETFILTER_PKT message format

Paul Moore
2017-02-16T00:32:51Z

On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:

...

>> > helpful action, hook
>>
>> I haven't checked, but do we allow setting of an audit key in
>> NETFILTER_PKT records? It seems like that might be a good thing for
>> the userspace tools and would likely make logging the action/hook
>> unncessary.
>
> Not that I am aware of. That would be way useful if it were possible.
> "AUDIT" is a netfilter target and you can set the type to "accept",
> "drop" or "reject". Similarly, having the sub-chain name would be
> useful but that doesn't appear to be available either. This is why I
> used a "mark" in the testsuite to track packets.

I've been thinking about this off and on and I think you are on to
something here ... the netfilter mark is very similar to what we do
with the audit keys and the audit-folk on this thread already know how
helpful audit keys can be for associating records with a specific [set
of] audit rules; I'm thinking we should treat the netfilter mark the
same way, after all, this is very much in keeping with how
netfilter/iptables uses the mark data. In an effort to simplify
things greatly for the NETFILTER_PKT record I'm going to offer the
following suggestion:

* Limit NETFILTER_PKT fields to only those present in the IPv4/IPv6
header, e.g. src/dest addresses and next level protocol, and the
netfilter mark.
* Teach ausearch and the other relevant audit userspace tools to
search on the netfilter mark much like they currently search on the
audit key.

This puts a reasonable bound on the fields in the NETFILTER_PKT record
and insulates us from protocol specifics (both very desirable things);
I also think we should be able to do this without having to introduce
a new record, e.g. NETFILTER_PKT2 (another big win). Any additional
packet information can be conveyed by the netfilter mark and careful
netfilter rule construction.

What do you think Richard?

--
paul moore