On 2017-02-13 18:50, Paul Moore wrote: > On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > On 2017-02-13 12:57, Steve Grubb wrote: > >> On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote: > >> > On 2017-02-10 17:39, Steve Grubb wrote: > >> > > > The alternatives that I currently see are to drop packets for which > >> > > > there is no local process ownership, or to leave the ownership fields > >> > > > unset.> > >> > > >> > > What ownership fields are we talking about? > >> > > >> > The ones you want, auid, pid, ses. Perhaps I'm using the wrong > >> > terminology. What technical term is there for the collection of subject > >> > identifiers? > >> > >> Subject attributes. > > > > Ah ok, I'll try to remember to use that term... > > > > Now that you know what I'm talking about, can you go back and answer the > > questions I had about packet "ownership" (which is really packet subject > > attributes)? If we have that information, how to we include it in the > > message format? And if we don't have it, do we ignore the packet, or do > > we swing fields out, or do we set those fields to "unset" or do we use > > an auxiliary record? > > Packet "ownership" is likely going to be impossible to determine > reliably since in some cases you can't even match a packet to a > socket, let alone a process. To back up a few messages in this > thread, to Richard's list of things to potentially log: > > > 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. > > useless? len > > I don't see much point in this. > > > helpful inif, outif, mark > > Let's split this into two things: the interfaces and the mark. I > don't see much value in logging the mark, but I could see some value > in logging the interface. In fact, the mark I found to be a useful way to track which rule was involved and I'd be pretty surprised if others don't try to do the same. > > 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? > > helpful protocol family > > I think we need some clarity on protocol logging; we've got "macproto" > (I assume this is the ethertype, or similar), "protocol family" (I > assume this to be a duplicate of ethertype, e.g. AF_INET), and "proto" > (see below, I assume this to be TCP/UDP/etc.). Sorry, you are right. I know that field as "ethertype" which defines the "protocol family" (network layer protocol, IPv4/6, etc...). "proto" is the transport layer protocol. For some reason, I was thinking "macproto" was the link layer type, but that's obvious from the media. > > useless? truncated > > Definitely useless. Only keep this if we need it for some backwards > compatibility. > > > helpful saddr, daddr > > Helpful. > > > useless? ipid > > Useless. > > > helpful proto > > helpful sport, dport > > Assuming "proto" means the TCP/UDP/etc. then we should treat the > proto/ports as one block; you can't log the ports without logging > "proto". > > > useless? frag > > useless? truncated > > Yes, useless. > > > helpful icmptype, icmpcode > > Similar to proto/port above. > > > 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. > 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
