Re: AUDIT_NETFILTER_PKT message format
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> 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>
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
paul moore
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635