Re: Audit record ordering requirements

From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Richard Guy Briggs <rgb@redhat.com>
Subject: Re: Audit record ordering requirements
Date: Fri, 27 Mar 2020 10:08:57 -0400	[thread overview]
Message-ID: <1624736.Ce3VpmeUTe@x2> (raw)
In-Reply-To: <2966967.03MRl4nvq3@x2>

On Friday, March 27, 2020 10:03:07 AM EDT Steve Grubb wrote:
> On Thursday, March 26, 2020 8:28:51 PM EDT Paul Moore wrote:
> > On Thu, Mar 26, 2020 at 7:49 PM Casey Schaufler <casey@schaufler-ca.com>
> 
> wrote:
> > > I'm looking at adding an audit record type for the case where
> > > there are multiple security modules providing subject data. There
> > > are several reasons to create a new record rather than adding the
> > > additional information to existing records, including possible
> > > size overflows and format compatibility.
> > > 
> > > While working with the code I have found that it is much easier
> > > if the new record (I'm calling it MAC_TASK_CONTEXTS) can be generated
> > > before the "base" record, which could be a SYSCALL record, than
> > > after it. Can I get away with this? I haven't seen any documentation
> > > that says the CWD record has to follow the event's SYSCALL record,
> > > but I wouldn't be at all surprised if it's implicitly assumed.
> > 
> > From a kernel perspective, as long as the timestamp matches (so it's
> > considered part of the same "event") I've got no problem with that.
> > However, Steve's audit userspace has a lot of assumptions about how
> > things are done so it's probably best that he comments on this so his
> > tools don't blow up.
> 
> There are some assumptions about what record is last in order to speed up
> "aging" the event during search so that we know the event is complete and
> ready for processing. We can always change that if needed. But a new kernel
> won't be compatible with older tools.
> 
> The only long term fix for this would be to have something that says how
> many records are in this event, then add a field for each record saying
> which one it is. Then we can have a reliable way to decide when we have
> all records ready for processing. This only affects searching/reporting,
> not logging.

Or I can make a change to put EOF to disk. Currently, that is not done to 
conserve disk space.

> But I think the records are in chronological order as the syscall traverses
> the various observers in the kernel. And as Paul said, as long as they all
> have the same timestamp/serial number, userspace will collect them all up.
> 
> -Steve
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit