On Wed, May 30, 2018 at 8:46 PM, Lenny Bruzenak <lenny(a)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