Re: Audit record ordering requirements
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(a)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