[RFC PATCH] New audit message for NetLabel static/fallback labels

[Paul Moore]

On Wednesday 21 November 2007 4:26:57 pm Paul Moore wrote:
> On Wednesday 21 November 2007 4:21:26 pm Linda Knippers wrote:
> > Paul Moore wrote:
> > > For reference, here are four examples of the new message types pulled
> > > from a Fedora Rawhide machine running this patch:
> > >
> > >  * adding new fallback label using network interface "lo" and
> > >    address "127.0.0.0/8"
> > >
> > >    type=UNKNOWN[1416] msg=audit(1195671777.849:32): netlabel: \
> > >     auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 \
> > >     netif=lo daddr=127.0.0.0 daddr_mask=8 \
> > >     sec_obj=system_u:object_r:unlabeled_t:s0 res=1
> >
> > At the risk of being nit-picky, it seems like the convention for network
> > addresses is either separate address and netmask fields, or the combined
> > address/bits-in-netmask notation.  For example, ifconfig (on ubuntu,
> > anyway) uses the former for IPv4 and the later for IPv6 addresses.
> >
> > lo        Link encap:Local Loopback
> >           inet addr:127.0.0.1  Mask:255.0.0.0
> >           inet6 addr: ::1/128 Scope:Host
> >
> > These audit records separate the two values but use the bits-in-netmask
> > instead of the netmask in dot notation, which seems inconsistent to me.
> > Seems like the audit record above should either have an address of
> > 127.0.0.0/8 or an address of 127.0.0.0 and a netmask of 255.0.0.0.
>
> I agree in that I like seeing the netmask attached to the address, but when
> I posed the question earlier to the list there was concern that this would
> cause breakage in the tools.  I just thought of something, would you be
> more comfortable if I changed the name from 'daddr_mask' to
> 'daddr_prefixlen'?

The more I think about this, the more I like the idea of 'daddr_prefixlen', 
I'm going to go and make that change.  Although I'm still unclear of how 
people would like to see the netmask information - part of the address or 
separate.

For what it is worth I think we are going to need to augment the existing 
IPsec SPD audit messages to include this information as well (see my other 
mail).

-- 
paul moore
linux security @ hp