Stephen Smalley wrote: > 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: >>>>>>> >>>>> >>>>>>>>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.
Thanks for the reminder about that thread. https://www.redhat.com/archives/redhat-lspp/2006-August/msg00008.html I didn't really see a conclusion though. Dan was waiting to hear from Steve. Steve didn't like it for the reasons I mentioned above. Were the auditallows added to the MLS policy? Did anyone create a module? -- ljk -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
