Linux-audit Archive on lore.kernel.org
 help / color / Atom feed
* Identifying thread/process termination
@ 2020-10-05 19:07 Natan Yellin
  2020-10-06 20:20 ` Steve Grubb
  0 siblings, 1 reply; 7+ messages in thread
From: Natan Yellin @ 2020-10-05 19:07 UTC (permalink / raw)
  To: linux-audit

[-- Attachment #1.1: Type: text/plain, Size: 644 bytes --]

Hello,
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?

For my use case, I would like to know when either processes or individual
threads execute and terminate. (I'm fine tracking at either granularity.)
Right now I can track the creation properly using fork/clone/etc but for
termination I receive multiple exit events with identical information that
doesn't let me know which thread died.

Thanks,
Natan

[-- Attachment #1.2: Type: text/html, Size: 746 bytes --]

[-- Attachment #2: Type: text/plain, Size: 102 bytes --]

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-05 19:07 Identifying thread/process termination Natan Yellin
@ 2020-10-06 20:20 ` Steve Grubb
  2020-10-08  1:27   ` Paul Moore
  0 siblings, 1 reply; 7+ messages in thread
From: Steve Grubb @ 2020-10-06 20:20 UTC (permalink / raw)
  To: linux-audit

Hello,

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?

-Steve

> For my use case, I would like to know when either processes or individual
> threads execute and terminate. (I'm fine tracking at either granularity.)
> Right now I can track the creation properly using fork/clone/etc but for
> termination I receive multiple exit events with identical information that
> doesn't let me know which thread died.




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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-06 20:20 ` Steve Grubb
@ 2020-10-08  1:27   ` Paul Moore
  2020-10-08  7:59     ` Natan Yellin
                       ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Paul Moore @ 2020-10-08  1:27 UTC (permalink / raw)
  To: Natan Yellin; +Cc: linux-audit

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

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-08  1:27   ` Paul Moore
@ 2020-10-08  7:59     ` Natan Yellin
  2020-10-09  1:12       ` Paul Moore
  2020-10-08 12:49     ` Richard Guy Briggs
  2020-10-08 15:33     ` Lenny Bruzenak
  2 siblings, 1 reply; 7+ messages in thread
From: Natan Yellin @ 2020-10-08  7:59 UTC (permalink / raw)
  To: Paul Moore; +Cc: linux-audit

[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2357 bytes --]

[-- Attachment #2: Type: text/plain, Size: 102 bytes --]

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-08  1:27   ` Paul Moore
  2020-10-08  7:59     ` Natan Yellin
@ 2020-10-08 12:49     ` Richard Guy Briggs
  2020-10-08 15:33     ` Lenny Bruzenak
  2 siblings, 0 replies; 7+ messages in thread
From: Richard Guy Briggs @ 2020-10-08 12:49 UTC (permalink / raw)
  To: Paul Moore; +Cc: linux-audit

On 2020-10-07 21:27, Paul Moore 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.

I would say that adding a thread ID rather than changing any existing
fields would be the safe way to go, but adds overhead and information to
wade through.

> paul moore

- 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-08  1:27   ` Paul Moore
  2020-10-08  7:59     ` Natan Yellin
  2020-10-08 12:49     ` Richard Guy Briggs
@ 2020-10-08 15:33     ` Lenny Bruzenak
  2 siblings, 0 replies; 7+ messages in thread
From: Lenny Bruzenak @ 2020-10-08 15:33 UTC (permalink / raw)
  To: linux-audit

On 10/7/20 7:27 PM, Paul Moore wrote:

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

That's right, Paul. The process (exe/comm) is the discriminator from a 
security perspective.

LCB

-- 
Lenny Bruzenak
MagitekLTD

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Identifying thread/process termination
  2020-10-08  7:59     ` Natan Yellin
@ 2020-10-09  1:12       ` Paul Moore
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Moore @ 2020-10-09  1:12 UTC (permalink / raw)
  To: Natan Yellin; +Cc: linux-audit

On Thu, Oct 8, 2020 at 4:00 AM Natan Yellin <aantny@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@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



-- 
paul moore
www.paul-moore.com


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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-05 19:07 Identifying thread/process termination Natan Yellin
2020-10-06 20:20 ` Steve Grubb
2020-10-08  1:27   ` Paul Moore
2020-10-08  7:59     ` Natan Yellin
2020-10-09  1:12       ` Paul Moore
2020-10-08 12:49     ` Richard Guy Briggs
2020-10-08 15:33     ` Lenny Bruzenak

Linux-audit Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-audit/0 linux-audit/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-audit linux-audit/ https://lore.kernel.org/linux-audit \
		linux-audit@redhat.com
	public-inbox-index linux-audit

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.redhat.linux-audit


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git