[PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions

[Paul Moore]

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