On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT > event messages and it is not quite as straightforward as I had expected. > > It is being tracked here: > https://github.com/linux-audit/audit-kernel/issues/11 > and refers to a previous posting from Mr. Dash Four from four years ago > to which there was no reply. > > The example given in the tracker above for "frag=" is fairly > straightforward, but digging more, there are a number of others that are > not quite so obvious. > > How many different combinations of fields is acceptable? Can we create > new message types for each one, or is there a preferred way to indicate > which sub-type it is other than implicit from the arguments given? That would be preferential to swinging fields in and out. But we also don't want to add too many new types. If two protocols look almost identical, I'd try to coerce them to be the same. If adding 2 new types solves the problem just do it. If it takes 10, then maybe we should understand why.

> Others that are straightforward: > - The first "truncated=" gets pulled in with "0". > > - "mark=" gets pulled in with "0". > > Ones that are not so straightforward: > - "secmark" depends on a kernel config setting, so should it always be > present but "(none)" if that kernel feature is compiled out? If this is selinux related, I'd treat it the same way that we do subj everywhere else.

> - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them > to "(none)" to indicate that type isn't present. "(none)" is for character fields that have nothing. Typically we set -1 for numeric fields that are unset. If numbers are expected, its going to get the strtol() treatment and "(none)" will cause a conversion error.

> - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4 > adds "ipid=", which would be set to "(none)" for ip6. That is numeric. -1?

-Steve > - audit_proto() pulls in "truncated=" again, then either "sport=" and > "dport=" OR "icmptype=" and "icmpcode=". > > If all fields are pulled in, we end up adding 10 fields beyond a > standard well-formed packet, and 15 beyond a truncated packet. > > Note: In the cases of "mark" and "secmark" both are unions. In the case of > "mark", I don't see a problem since it isn't conditionally compiled out > and won't be mis-interpreted. In the case of "secmark=", it could be > mis-interpreted as offload_fwd_mark if that field is even compiled in, > but that would be addressed in the compiler directive... > > > One last question: Does anyone have a test suite that can generate any > or all of these types of packets? > > > Thanks! > > > - RGB

On 2017-01-17 11:12, Richard Guy Briggs wrote: > On 2017-01-17 08:55, Steve Grubb wrote: > > On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: > > > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT > > > event messages and it is not quite as straightforward as I had > > > expected. > > > > > > It is being tracked here: > > > https://github.com/linux-audit/audit-kernel/issues/11 > > > > > > and refers to a previous posting from Mr. Dash Four from four years > > > ago > > > to which there was no reply. > > > > > > The example given in the tracker above for "frag=" is fairly > > > straightforward, but digging more, there are a number of others that > > > are > > > not quite so obvious. > > > > > > How many different combinations of fields is acceptable? Can we > > > create > > > new message types for each one, or is there a preferred way to > > > indicate > > > which sub-type it is other than implicit from the arguments given? > > > > That would be preferential to swinging fields in and out. But we also > > don't > > want to add too many new types. If two protocols look almost identical, > > I'd > > try to coerce them to be the same. If adding 2 new types solves the > > problem > > just do it. If it takes 10, then maybe we should understand why. > > Ok, I'll have a go at mapping some out and see where we end up... > > > > Others that are straightforward: > > > - The first "truncated=" gets pulled in with "0". > > > > > > - "mark=" gets pulled in with "0". > > > > > > Ones that are not so straightforward: > > > - "secmark" depends on a kernel config setting, so should it always be > > > > > > present but "(none)" if that kernel feature is compiled out? > > > > If this is selinux related, I'd treat it the same way that we do subj > > everywhere else. > > Ok. > > > > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set > > > them > > > > > > to "(none)" to indicate that type isn't present. > > > > "(none)" is for character fields that have nothing. Typically we set -1 > > for > > numeric fields that are unset. If numbers are expected, its going to get > > the strtol() treatment and "(none)" will cause a conversion error. > > Ah, ok. I certainly don't want to break the parser, so I'll use -1 or > find another way to indicate it. > > > > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4 > > > > > > adds "ipid=", which would be set to "(none)" for ip6. I assume that v4, v6 and mac address fields count as text?

> > That is numeric. -1? > > Yup, 16-bit. I'll make it -1. > > > -Steve > > > > > - audit_proto() pulls in "truncated=" again, then either "sport=" and > > > > > > "dport=" OR "icmptype=" and "icmpcode=". > > > > > > If all fields are pulled in, we end up adding 10 fields beyond a > > > standard well-formed packet, and 15 beyond a truncated packet. > > > > > > Note: In the cases of "mark" and "secmark" both are unions. In the > > > case of > > > "mark", I don't see a problem since it isn't conditionally compiled > > > out > > > and won't be mis-interpreted. In the case of "secmark=", it could be > > > mis-interpreted as offload_fwd_mark if that field is even compiled in, > > > but that would be addressed in the compiler directive... > > > > > > > > > One last question: Does anyone have a test suite that can generate any > > > or all of these types of packets? > > > > > > > > > Thanks! > > > > > > > > > - RGB > > - 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 - 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

On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-01-17 08:55, Steve Grubb wrote: >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: ... >> > Ones that are not so straightforward: >> > - "secmark" depends on a kernel config setting, so should it always be >> > present but "(none)" if that kernel feature is compiled out? >> >> If this is selinux related, I'd treat it the same way that we do subj >> everywhere else. > > Ok. To be clear, a packet's secmark should be recorded via a dedicated field, e.g. "secmark", and not use the "subj" field (it isn't a subject label in the traditional sense).

paul moore

On 2017-01-17 21:34, Richard Guy Briggs wrote: > On 2017-01-17 15:17, Paul Moore wrote: > > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > On 2017-01-17 08:55, Steve Grubb wrote: > > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: > > > > ... > > > > >> > Ones that are not so straightforward: > > >> > - "secmark" depends on a kernel config setting, so should it always be > > >> > present but "(none)" if that kernel feature is compiled out? > > >> > > >> If this is selinux related, I'd treat it the same way that we do subj > > >> everywhere else. > > > > > > Ok. > > > > To be clear, a packet's secmark should be recorded via a dedicated > > field, e.g. "secmark", and not use the "subj" field (it isn't a > > subject label in the traditional sense). > > I think Steve was talking about if, when or where to include that field, > not what its label is. In this case it is an "obj=" field, but since it is part of the LSM, each one has its own fields.

On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-01-17 21:34, Richard Guy Briggs wrote: >> On 2017-01-17 15:17, Paul Moore wrote: >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: >> > > On 2017-01-17 08:55, Steve Grubb wrote: >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: >> > >> > ... >> > >> > >> > Ones that are not so straightforward: >> > >> > - "secmark" depends on a kernel config setting, so should it always be >> > >> > present but "(none)" if that kernel feature is compiled out? >> > >> >> > >> If this is selinux related, I'd treat it the same way that we do subj >> > >> everywhere else. >> > > >> > > Ok. >> > >> > To be clear, a packet's secmark should be recorded via a dedicated >> > field, e.g. "secmark", and not use the "subj" field (it isn't a >> > subject label in the traditional sense). >> >> I think Steve was talking about if, when or where to include that field, >> not what its label is. > > In this case it is an "obj=" field, but since it is part of the LSM, > each one has its own fields. As I said above, use a "secmark" field and not the subject or object fields; packet labeling is rather complex and there is value in differentiating between secmark labels and network peer labels.

paul moore

On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-01-18 07:32, Paul Moore wrote: >> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb(a)redhat.com&gt;

>> > On 2017-01-17 21:34, Richard Guy Briggs wrote: >> >> On 2017-01-17 15:17, Paul Moore wrote: >> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs

>> >> > > On 2017-01-17 08:55, Steve Grubb wrote: >> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs

>> >> > ... >> >> > >> >> > >> > Ones that are not so straightforward: >> >> > >> > - "secmark" depends on a kernel config setting, so should it >> >> > >> > always be >> >> > >> > >> >> > >> > present but "(none)" if that kernel feature is compiled out? >> >> > >> >> >> > >> If this is selinux related, I'd treat it the same way that we do >> >> > >> subj >> >> > >> everywhere else. >> >> > > >> >> > > Ok. >> >> > >> >> > To be clear, a packet's secmark should be recorded via a dedicated >> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a >> >> > subject label in the traditional sense). >> >> >> >> I think Steve was talking about if, when or where to include that >> >> field, >> >> not what its label is. >> > >> > In this case it is an "obj=" field, but since it is part of the LSM, >> > each one has its own fields. >> >> As I said above, use a "secmark" field and not the subject or object >> fields; packet labeling is rather complex and there is value in >> differentiating between secmark labels and network peer labels. > > Ok, I'll change it from the existing "obj=" to "secmark=". Since it is > an LSM-dependent field, it will go away when that LSM module does. It > is the very last item in the list of fields, so I don't see this as a > problem. > > > I have more questions and observations: > > Do we care if the rest of the record's fields are there if the packet is > truncated? In other words, can I omit all the following fields (that > will end up being set to (none) or -1 since there is no data for them)? > I'd prefer to complete the record, but Steve may not care and might > prefer to save the bandwidth. > > Can I truncate the field name "truncated" to "trunc" (since I don't see > it yet in the audit field dictionary) if we do include all the fields? > > I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added > virtually for free since the source and desination ports in their packet > formats is identical to TCP and UDP (and UDPLITE). > > > At this point, it looks like having one record for IP/IPv6 with > TCP/UDP/DCCP/SCTP makes sense. Whether or not to add ethernet bridge > headers and ICMP* is a more difficult question. Ethernet bridge adds 40 > chars if it isn't used, up to 62 if it is. ICMP* adds 26 max. > > It is an independent record, but it would be nice to be able to reuse > the message ID with a new record type to list sub-parts of the packet, > for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for > the first 5 fields, mark and secmark, then another record type > (AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record > (AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another > (AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol. This way, the > absence of an ethernet bridge header won't swing out three fields, or > waste 40 chars. IPv4 adds about 20 chars not used by IPv6. > TCP/UDP/DCCP/SCTP vs ICMP* is about 25 chars each. The max message is > 322 chars (eth bridge, IPv6). A non-ethernet-bridge non-IP* message > would be as little as 76 without the extra fields, but as much as 219 > with the extra fields filled with unset values. > > A full message could look like (I've left off secmark, which would go at > the end): action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ > mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF > macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF > daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1 > trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999 At this point I think it would be good to hear what requirements exist for per-packet auditing. Steve, are there any current Common Criteria (or other) requirements that impact per-packet auditing?

On Fri, Jan 20, 2017 at 9:49 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote: >> At this point I think it would be good to hear what requirements exist >> for per-packet auditing. Steve, are there any current Common Criteria >> (or other) requirements that impact per-packet auditing? > I don't think you want to flood your logs. That is not helpful. It asks for the > ability to detect information flow. Typically you want to know source and > destination, protocol, where on the system its coming from or going to, pid if > possible and the subject information if available. I know that you can be > acting as a proxy and forwarding outside packets into a network. That is not > the typical case CC is concerned about. Its more about what the user is doing. Determining the pid/subj of a packet is notoriously difficult/impossible in netfilter so let's drop that; with proper policy/rules you should be able to match proto/port with a given process so this shouldn't be that critical. The source/destination addresses and proto/port (assuming IP) should be easy enough. All right, now that we've got the "must" items down, are their any "should" items we want?

On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL <patrick.pignol(a)gmail.com&gt; wrote: > Hi all, > > I disagree ! > > Many people in the world would like to allow an software A to go to internet > through OUTPUT TCP port 80 but disallow software B to go to the internet > through this same OUTPUT TCP port 80. Don't you know about viruses on linux > ? Viruses ALWAYS use HTTP/HTTPS ports to get payloads on internet and OUTPUT > TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE if you want to access > internet services (via internet browsers for example). The Linux audit subsystem simply logs system events, it does not enforce security policy. I suggest you investigate the different Linux firewall tools and LSMs, e.g. SELinux, as they should help you accomplish what you describe.

On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote: > On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2017-01-18 07:32, Paul Moore wrote: > >> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > >> > On 2017-01-17 21:34, Richard Guy Briggs wrote: > >> >> On 2017-01-17 15:17, Paul Moore wrote: > >> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > >> >> > > On 2017-01-17 08:55, Steve Grubb wrote: > >> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: > >> >> > ... > >> >> > > >> >> > >> > Ones that are not so straightforward: > >> >> > >> > - "secmark" depends on a kernel config setting, so should it > >> >> > >> > always be > >> >> > >> > > >> >> > >> > present but "(none)" if that kernel feature is compiled out? > >> >> > >> > >> >> > >> If this is selinux related, I'd treat it the same way that we do > >> >> > >> subj > >> >> > >> everywhere else. > >> >> > > > >> >> > > Ok. > >> >> > > >> >> > To be clear, a packet's secmark should be recorded via a dedicated > >> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a > >> >> > subject label in the traditional sense). > >> >> > >> >> I think Steve was talking about if, when or where to include that > >> >> field, > >> >> not what its label is. > >> > > >> > In this case it is an "obj=" field, but since it is part of the LSM, > >> > each one has its own fields. > >> > >> As I said above, use a "secmark" field and not the subject or object > >> fields; packet labeling is rather complex and there is value in > >> differentiating between secmark labels and network peer labels. > > > > Ok, I'll change it from the existing "obj=" to "secmark=". Since it is > > an LSM-dependent field, it will go away when that LSM module does. It > > is the very last item in the list of fields, so I don't see this as a > > problem. > > > > > > I have more questions and observations: > > > > Do we care if the rest of the record's fields are there if the packet is > > truncated? In other words, can I omit all the following fields (that > > will end up being set to (none) or -1 since there is no data for them)? > > I'd prefer to complete the record, but Steve may not care and might > > prefer to save the bandwidth. > > > > Can I truncate the field name "truncated" to "trunc" (since I don't see > > it yet in the audit field dictionary) if we do include all the fields? > > > > I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added > > virtually for free since the source and desination ports in their packet > > formats is identical to TCP and UDP (and UDPLITE). > > > > > > At this point, it looks like having one record for IP/IPv6 with > > TCP/UDP/DCCP/SCTP makes sense. Whether or not to add ethernet bridge > > headers and ICMP* is a more difficult question. Ethernet bridge adds 40 > > chars if it isn't used, up to 62 if it is. ICMP* adds 26 max. > > > > It is an independent record, but it would be nice to be able to reuse > > the message ID with a new record type to list sub-parts of the packet, > > for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for > > the first 5 fields, mark and secmark, then another record type > > (AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record > > (AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another > > (AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol. This way, the > > absence of an ethernet bridge header won't swing out three fields, or > > waste 40 chars. IPv4 adds about 20 chars not used by IPv6. > > TCP/UDP/DCCP/SCTP vs ICMP* is about 25 chars each. The max message is > > 322 chars (eth bridge, IPv6). A non-ethernet-bridge non-IP* message > > would be as little as 76 without the extra fields, but as much as 219 > > with the extra fields filled with unset values. > > > > A full message could look like (I've left off secmark, which would go at > > the end): action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ > > mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF > > macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF > > daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1 > > trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999 > > At this point I think it would be good to hear what requirements exist > for per-packet auditing. Steve, are there any current Common Criteria > (or other) requirements that impact per-packet auditing? I don't think you want to flood your logs. That is not helpful. It asks for the ability to detect information flow. Typically you want to know source and destination, protocol, where on the system its coming from or going to, pid if possible and the subject information if available. I know that you can be acting as a proxy and forwarding outside packets into a network. That is not the typical case CC is concerned about. Its more about what the user is doing.

-Steve

On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > So while I'm not advocating this is what should be done and I'm trying > to establish bounds to the scope of this feature, but would it be > reasonable to simply not log packets that were transiting this machine > without a local endpoint? I'm still waiting on more detailed requirements information from Steve, but based on what we've heard so far, it seems that ignoring forwarded traffic is a reasonable thing to do.

On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote: >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: >> > So while I'm not advocating this is what should be done and I'm trying >> > to establish bounds to the scope of this feature, but would it be >> > reasonable to simply not log packets that were transiting this machine >> > without a local endpoint? >> >> I'm still waiting on more detailed requirements information from >> Steve, but based on what we've heard so far, it seems that ignoring >> forwarded traffic is a reasonable thing to do. > > OK, I have done teh analysis to see where things stand on this ... ... > At this point, I would say there is no purpose for xt_AUDIT.c based on Common > Criteria. It looks like its built in response to the > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly > deprecated. Based on some off-list discussions with Richard it would appear that there are several users of the NETFILTER_PKT record so I am in no hurry to deprecate it. Considering that there are no CC requirements on the record, I think we can focus on simply providing a basic record that satisfies the whims of the userspace tools without adding any pain to the kernel. I believe Richard is currently working on a proposal to do that, let's discuss it further in that thread.

On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote: >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: >> > So while I'm not advocating this is what should be done and I'm trying >> > to establish bounds to the scope of this feature, but would it be >> > reasonable to simply not log packets that were transiting this machine >> > without a local endpoint? >> >> I'm still waiting on more detailed requirements information from >> Steve, but based on what we've heard so far, it seems that ignoring >> forwarded traffic is a reasonable thing to do. > > OK, I have done the analysis to see where things stand on this ... ... > At this point, I would say there is no purpose for xt_AUDIT.c based on Common > Criteria. It looks like its built in response to the > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly > deprecated. Based on some off-list discussions with Richard it would appear that there are several users of the NETFILTER_PKT record so I am in no hurry to deprecate it. Considering that there are no CC requirements on the record, I think we can focus on simply providing a basic record that satisfies the whims of the userspace tools without adding any pain to the kernel. I believe Richard is currently working on a proposal to do that, let's discuss it further in that thread.

paul moore

On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote: > On 2017-02-08 18:09, Paul Moore wrote: > > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote: > > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > >> > So while I'm not advocating this is what should be done and I'm > > >> > trying > > >> > to establish bounds to the scope of this feature, but would it be > > >> > reasonable to simply not log packets that were transiting this > > >> > machine > > >> > without a local endpoint? > > >> > > >> I'm still waiting on more detailed requirements information from > > >> Steve, but based on what we've heard so far, it seems that ignoring > > >> forwarded traffic is a reasonable thing to do. > > > > > > OK, I have done the analysis to see where things stand on this ... > > > > ... > > > > > At this point, I would say there is no purpose for xt_AUDIT.c based on > > > Common Criteria. It looks like its built in response to the > > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly > > > deprecated. > > > > Based on some off-list discussions with Richard it would appear that > > there are several users of the NETFILTER_PKT record so I am in no > > hurry to deprecate it. Considering that there are no CC requirements > > on the record, I think we can focus on simply providing a basic record > > that satisfies the whims of the userspace tools without adding any > > pain to the kernel. I believe Richard is currently working on a > > proposal to do that, let's discuss it further in that thread. > > 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. There's no actual rule on this, but its not expected and I'd have to check to see what this would do to the parsers. The main drawback is that just setting up an auxiliary record is going to eat 40 bytes without the record name. That will also make processing them more difficult because information is on multiple lines. And we'd need clear rules about what the last record is to know when the event is complete if they are interlaced.

> 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... 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 biiger problem than just the audit logs.

> 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 want to see proto near the begining to guid interpretation of later fields.

From a network perspective that doesn't make sense, unless you flip

> 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? I prefer seeing 4 event types that follow an exact order everytime.

> If so, we're trying to find a balance between message type explosion and > disk bandwidth. 4 is not really an explosion. However, there is no actual requirement for these events any more. If we are going to keep them, the really should follow an exact order each time.

-Steve > 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.

On Thursday, February 9, 2017 8:12:47 PM EST Richard Guy Briggs wrote: > On 2017-02-09 19:09, Steve Grubb wrote: > > On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote: > > > On 2017-02-08 18:09, Paul Moore wrote: > > > > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > > > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote: > > > > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; > > > > wrote: > > > > >> > So while I'm not advocating this is what should be done and I'm > > > > >> > trying > > > > >> > to establish bounds to the scope of this feature, but would it be > > > > >> > reasonable to simply not log packets that were transiting this > > > > >> > machine > > > > >> > without a local endpoint? > > > > >> > > > > >> I'm still waiting on more detailed requirements information from > > > > >> Steve, but based on what we've heard so far, it seems that ignoring > > > > >> forwarded traffic is a reasonable thing to do. > > > > > > > > > > OK, I have done the analysis to see where things stand on this ... > > > > > > > > ... > > > > > > > > > At this point, I would say there is no purpose for xt_AUDIT.c based > > > > > on > > > > > Common Criteria. It looks like its built in response to the > > > > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be > > > > > cleanly > > > > > deprecated. > > > > > > > > Based on some off-list discussions with Richard it would appear that > > > > there are several users of the NETFILTER_PKT record so I am in no > > > > hurry to deprecate it. Considering that there are no CC requirements > > > > on the record, I think we can focus on simply providing a basic record > > > > that satisfies the whims of the userspace tools without adding any > > > > pain to the kernel. I believe Richard is currently working on a > > > > proposal to do that, let's discuss it further in that thread. > > > > > > 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. > > > > There's no actual rule on this, but its not expected and I'd have to check > > to see what this would do to the parsers. The main drawback is that just > > setting up an auxiliary record is going to eat 40 bytes without the > > record name. That will also make processing them more difficult because > > information is on multiple lines. And we'd need clear rules about what > > the last record is to know when the event is complete if they are > > interlaced. > > I agree it is not ideal. So could you please commit to an alternative > that works so we can move forward? I am trying to strongly discourage adding auxiliary records like we do for syscalls.

> 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?

> > > 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... > > > > 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 > > biiger 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.

> > > 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 want to see proto near the begining to guid interpretation of later > > fields. > > From a network perspective that doesn't make sense, unless you flip > around the entire set of fields. "pfam" is "protocol family", encoded > in the ethernet or hardware link headers to point to which address > family so we can decode the next two fields, then inside the "pfam" > header is a field that tells us the protocol, which helps us decode the > next two port/icmp fields. Network folks using this are likely to care > about the order. Is there a performance issue that concerns you? Leave it as you proposed it.

> > > 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? > > > > I prefer seeing 4 event types that follow an exact order everytime. > > I am leaning this way myself. > > > > If so, we're trying to find a balance between message type explosion and > > > disk bandwidth. > > > > 4 is not really an explosion. However, there is no actual requirement for > > these events any more. If we are going to keep them, the really should > > follow an exact order each time. > > What about ownership information? Do you have any suggestions how to > add this to what we have? What ownership information are you talking about?

-Steve > > > 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

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.

> > > > 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 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.

-Steve

On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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.

> 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.

> useless? smac, dmac, macproto Probably useless in the majority of use cases.

> 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.).

> 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.

paul moore

On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-02-13 18:50, Paul Moore wrote: >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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.

>> > 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.

paul moore

On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-02-13 18:50, Paul Moore wrote: >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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

[NOTE: I'll respond back to the other part of your email later but I'm running out of time in the day and this was a quick but important response] On Thu, Feb 16, 2017 at 5:36 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > Steve has requested the subject attributes which prefixes 7 fields. I already commented on this earlier in this thread - or some other related thread, I've lost track, but both you and Steve were on the To/CC line - last time I checked, you can't reliably link packets to the sender/subject in the netfilter hooks (I'll be shocked if this has changed). The best you can do in some cases is to link the packet to the socket, and that isn't going to help you.

paul moore

On 2017-02-13 18:50, Paul Moore wrote: > On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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?

> > - RGB > > paul moore - RGB

On Monday, February 13, 2017 3:50:05 PM EST Richard Guy Briggs 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)? The format for subject attributes would be: pid, uid, auid, ses, subj, comm, exe, ...then whatever else you want to add This also goes for the netfilter_cfg events.

> 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? If you have this for the majority of events, I'd say leave it unset when you don't. We really don't care about packets that simply transit through the system. Also, I suppose it depends on what kind of packet it is. For example, a icmp echo sent to the machine that is blocked is obviously not going to have an owner. But one originating in the machine heading out should.

-Steve