[redhat-lspp] Re: RHEL5 Kernel with labeled networking

Stephen Smalley sds at tycho.nsa.gov
Wed Oct 4 14:57:16 UTC 2006


On Tue, 2006-10-03 at 18:59 -0400, Linda Knippers wrote:
> Joshua Brindle wrote:
> > Linda Knippers wrote:
> >> Karl MacMillan wrote:
> >>> Linda Knippers wrote:
> >>>> Joshua Brindle wrote:
> >>>>> Linda Knippers wrote:
> >>>>>
> >>>
> >>> <snip>
> >>>
> >>>    
> >>>
> >>>>>> If we go the auditallow route then we lose some audit record
> >>>>>> management
> >>>>>> features, like the ability to enable/disble/search for these records,
> >>>>>> don't we?  Do we care?
> >>>>>>           
> >>>>>
> >>>>> enable and disable with a boolean
> >>>>>
> >>>>> searching? surely you can search avc records..
> >>>>>         
> >>>>
> >>>> I meant with the audit tools, so using auditctl to add/remove rules and
> >>>> ausearch for looking for specific record types.
> >>>>         
> >>>
> >>>  
> >>> As I said in my other mail the searching should be fine. Why does the
> >>> addition or removal need to be handled by auditctl?
> >>>     
> >>
> >>
> >> There was a discussion a long, long time about about how
> >> administrators should
> >> manage what gets into the audit logs, whether its with the audit
> >> tools, the
> >> policy or both.  There are explicit message types for alot of management
> >> operations so that the admin can decide whether to get them and the tools
> >> make it easy to search for.  If changing the ipsec label configuration
> >> is just
> >> an AVC message, it will be different from just about everything else. 
> >> It might
> >> be easy, but is it what we want?
> >>
> >>   
> > 
> > what about relabeling files? or setting secmark labels? or domain
> > transitions? setexec(), etc. I'm very skeptical that lspp requires any
> > kind of auditing of ipsec label change but none of these. 
> 
> It has a requirement to be able to audit all modifications of the
> values of security attributes, so we can audit a bunch of syscalls
> that do that (chmod, chown, setxattr, ...).  Relabeling files
> would definitely count and be covered.  There's also a requirement about
> auditing changes to the way data is imported/exported, so this is where
> the networking stuff comes in.  I don't know about domain transitions.
> 
> > Further, all
> > the others are in policy, you want to special case ipsec? and for that
> > matter just the spd rules which is pretty much useless without
> > accompanying polmatch rules. I'm very dubious about this entire thread.
> 
> I'm not trying to special case ipsec.  In fact, that was the point of
> my comment.  In general, we have explicit message types for the things
> that we care about auditing.  Paul added auditing for the netlabel
> configuration changes because the only other way to know about the
> changes would be watching the netlink messages.
> 
> I asked the question about using auditallow because its different from
> how all the other things that lspp cares about are handled from an
> audit administrator's perspective.  I personally don't care that much
> either way but if its going to be different, folks ought to know,
> especially the folks who have to document and test it.

As I recall, auditallow was deemed acceptable for auditing of writing to
the /proc/self/attr nodes earlier on redhat-lspp.  Note that auditallow
yields not only the avc audit message but also causes a syscall audit
record to be emitted upon syscall exit.  The best thing to do is to
actually try it and see whether the resulting data meets your need.

-- 
Stephen Smalley
National Security Agency




More information about the redhat-lspp mailing list