Re: AUDIT_NETFILTER_PKT message format

On 2017-02-08 18:09, Paul Moore wrote: If there is no strict rule about turning any other type of record other than SYSCALLs into compound records, we could add the user credentials if they are identifyable without having a number of unset fields by using an auxilliary record. If this isn't possible or desirable, we'd need to include those fields as unset in every message unless we discard messages for which there is no identifying information. We probably don't want to trot out all the fields in a packet like tcpdump does, since many of them won't be of interest to us. We want protocol family, end points, type of packet. The ones that would be quite useful but may be hard to get are pid, auid, sessionid. There is no packet for which all fields are valid. This is why using "unset" values in those fields was suggested. I'd start by splitting data from control protocols if we even need source/destination ports or icmp* details. Those seem like pretty important details, so I think we need to start there. I'd be inclined to use the same message type for IPv4 and IPv6 and just drop the IPv4-specific fields, or include them with the IPv6 record and set them to "unset" (ipid, frag). As for the MAC (Media Access Control) addresses I'm not sure what to recommend. We could fill them in with the outer MAC, we could leave them as unset or could just delete them entirely. Source IP addresses can be easily spoofed, particularly for UDP, so they are not particularly useful and a MAC may have more useful information if there are multiple potential local sources. Depending on the local hardware there is usually a MAC address, but may have been stripped by the time we see that packet, but I think it is worth adding, but not sure the best way to do this if there is a second MAC for tunnelling, etc... Ok, with that guidance... from the start of the message: helpful action, hook useless? len helpful inif, outif, mark useless? smac, dmac, macproto helpful protocol family useless? truncated helpful saddr, daddr useless? ipid helpful proto useless? frag useless? truncated helpful sport, dport helpful icmptype, icmpcode helpful secmark (I forgot to change it from "obj" to "secmark" in my patch). I agree truncate is not helpful, neither is ipid or frag I'm guessing. I'm not sure what the 3 MAC fields give us, other than some idea of routing information (which might actually be useful in this context due to the ease of IP addr and port spoofing). I'd be tempted to add a network protocol field between mark and saddr. That could potentially bring us down to 4 distinct messages with no useless fields: -IP data -action, hook, inif, outif, mark, pfam, saddr, daddr, proto, sport, dport[, secmark] -IP control -action, hook, inif, outif, mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark] -other IP -action, hook, inif, outif, mark, pfam, saddr, daddr, proto[, secmark] -other non-IP -action, hook, inif, outif, mark, pfam[, secmark] I'd like to see a CHAIN name in there, but that doesn't appear to be available, so we'd have to make do with the "mark" field. (I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.) 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 more fine-grained by message type, ignore fields that aren't valid for that type indicated with "unset", or swing fields in and out. - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635