On Wed, May 30, 2018 at 8:46 PM, Lenny Bruzenak <le...@magitekltd.com> wrote: > On 05/30/2018 06:54 PM, Paul Moore wrote: > > ... > >> Finally, since you probably haven't followed all of the discussion >> around associating records into a single event, I wanted to give you >> my side of the story (if you don't care, you can simply skip the rest >> of this email). Currently an audit "event" can consist of multiple >> audit "records"; these records can contain PATH information, SYSCALL >> information, SELinux AVC information, as well as INTEGRITY_PCR >> information. The current kernel code does a poor job of associating >> some of these record types, which can make a single user action look >> like multiple audit events. For example, a single user action/event >> (writing a new IMA policy) could result in multiple audit "events" >> because the SYSCALL record for the write() syscall is not associated >> with the INTEGRITY_POLICY_RULE record; this is bogus because the write >> syscall is inherently linked with the IMA policy update. Keeping the >> records as separate audit "events" is not only conceptually odd, it is >> misleading. > > A vote of support from the user side; thanks Paul for this. The > misleading part of having multiple events for what is conceptually a > unitary event makes life really hard on guys like me trying to explain > to security people what happened when. So while I understand it can be > challenging to associate those events in the kernel, particularly when > they occur at spaced times, trying to patch those together on the > analysis side is problematic too (which I know you well understand). So > - your effort to keep these these records tied to one event is very much > appreciated!
Thanks Lenny, I appreciate the feedback. We should have better connection between records when we make the audit container ID changes, if not sooner. <fingers crossed> -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit