On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <r...@redhat.com> wrote: > On 2017-01-18 07:32, Paul Moore wrote: >> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <r...@redhat.com> 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 <r...@redhat.com> >> >> > 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? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
