What would be so messy about adding the extra field?

I'm happy to put together a patch myself which adds it to all syscalls and
to process lifecycle events. My goal isn't to identify the exact thread
that performs every audit event but rather to allow tracking thread
lifecycle which isn't currently possible.

Natan

On Thu, Oct 8, 2020, 04:27 Paul Moore <paul@paul-moore.com> wrote:

> On Tue, Oct 6, 2020 at 4:20 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Monday, October 5, 2020 3:07:12 PM EDT Natan Yellin wrote:
> > > I've been tracking all process terminations using a rule for the exit
> and
> > > exit_group syscalls. However, by looking at the audit events for exit
> it is
> > > impossible to differentiate between the death of different threads in
> the
> > > same thread group. Is there an alternative way to track this?
> >
> > I don't think the audit system was ever designed to distinguish between
> > threads. But there is a general need to determine the exit of a process
> > rather than a thread.
> >
> > Paul, Richard, Do you have any thoughts?
>
> Almost everywhere in the kernel we record the TGID for the "pid="
> values and not the actual task/thread ID.  That decision was made
> before my heavy involvement with audit, but my guess is that most
> audit users are focused more on security relevant events at the
> process level, not the thread level.  After all, there isn't really
> much in the way of significant boundaries between threads.
>
> To get the information you are looking for, I think we would need to
> add an additional task/thread ID to the relevant records and that
> would be *very* messy.
>
> --
> paul moore
> www.paul-moore.com
>