Audit record ordering requirements

Audit record ordering requirements

[Casey Schaufler]

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.

Thanks.



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

Re: Audit record ordering requirements

[Paul Moore]

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.

-- 
paul moore
www.paul-moore.com


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

Re: 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@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


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

Re: Audit record ordering requirements

[Steve Grubb]

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

Re: Audit record ordering requirements

[Richard Guy Briggs]

On 2020-03-27 10:08, Steve Grubb wrote:
> 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.

I was going to say.  We already had that functionality.  It was recently
deleted.  An EOF isn't a big record.

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

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

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

Re: Audit record ordering requirements

[Casey Schaufler]

On 3/27/2020 7:03 AM, 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.
>
> 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.

Most excellent. Considerable complexity averted.

>
> -Steve
>
>


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