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(a)paul-moore.com> wrote:
On Tue, Oct 6, 2020 at 4:20 PM Steve Grubb <sgrubb(a)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