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? > > > > > I don't think audit should worry about spoofing. Yes it can be done, > > > > > but we should accurately record what was presented to the system. > > > > > Other tools can be employed to watch for arp spoofing and source routed > > > > > packets. Its a bigger problem than just the audit logs. > > > > > > > > I find this statement a bit surprising given we're trying to find out > > > > who's doing what where. > > > > > > We're just recording what's presented to the system that meets the rules > > > programmed in. > > > > I don't quite understand. Are you saying only display the fields that > > were specifically used in the netfilter rule to trigger the target that > > records a packet? > > No. I'm saying we shouldn't do any processing to figure out if we have a > spoofed or source routed packet. There are other tools that do that kind of > thing. I never suggested that. I only suggested including that information so that some other tool actually has the information to work with. > > I don't think that's what you want and it isn't easy > > to get without being more invasive in netfilter and swinging fields. > > I'd record the MAC header since it is part of the packet that tells us > > where it came from and where it's going. > > Do we really need the MAC header for every event? I really don't think so. It certainly makes my job simpler to just ignore the MAC header and avoid complicating things, but if I were a network admin and a packet came in that I wasn't expecting because of other network rules that had been set up to prevent it, I'd want more information to figure out why. > -Steve - 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
