Audit record ordering requirements

[Steve Grubb]

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 at 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.

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