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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
