On 2017-02-14 16:06, Paul Moore wrote: > On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > On 2017-02-13 18:50, Paul Moore wrote: > >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > ... > > >> > useless? smac, dmac, macproto > >> > >> Probably useless in the majority of use cases. > > > > How do we deal with the minority of cases where it could be quite useful? > > First you first need to show me why I should care about this, in other > words, why *must* you have the fields in the audit record. Well, as I've just argued in my other reply, the only fields that are a *must* are the subject attributes and the nfmark. You've jettisoned the ports while keeping the addresses, which puzzles me other than for expediancy. MAC, IP and ports can all be spoofed, each layer easier as you get higher, but it is all potentially useful information. > >> > helpful secmark (I forgot to change it from "obj" to "secmark" in my patch). > >> > >> We may also want to log the peer label if we are going to log the secmark. > > > > Ok, noted. > > Please note well the "*if*" portion in the above statement. I'm not > overly convinced that either field is all that useful in the majority > of cases. Thank you for that reminder to link the two. > paul moore - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
