Re: AUDIT_NETFILTER_PKT message format

Paul Moore
2017-01-18T23:35:33Z

On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-01-18 07:32, Paul Moore wrote:
>> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@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 <rgb@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