On Thu, Mar 26, 2020 at 7:49 PM Casey Schaufler <casey(a)schaufler-ca.com&gt;

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

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(a)schaufler-ca.com&gt; > > 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