Re: Identifying thread/process termination
On Thu, Oct 8, 2020 at 4:00 AM Natan Yellin <aantny(a)gmail.com> wrote:
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.
*Please* don't top post, it's a pain to read and it messes up the thread.
As far as recording the thread information, what I meant by messy is
that any new fields added to a record need to be added to the end[1],
which may result in some ugly code. Of course, if it's important to
you I would encourage you to develop a RFC patch and send it off to
the list for review. Maybe it won't be so messy after all! :)
[1] It's a really long story, involving a lot of screaming, so just
trust me on this one. If you really want to challenge this assertion
go read the past seven to eight years of linux-audit archives first ;)
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
--
paul moore
www.paul-moore.com