2:07 p.m.
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
3:20 p.m.
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.
8:27 p.m.
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
2:59 a.m.
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
8:12 p.m.
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
7:49 a.m.
On 2020-10-07 21:27, Paul Moore 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.
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(a)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
10:33 a.m.
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
12:41 a.m.
On 2020/10/08 08:33, Lenny Bruzenak wrote:
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.
----
So, when different threads perform / execute different functionality
as loaded by a runtime loadable libraries, how is that discriminated
from the initially started program?
Often, programs with many threads will rename the threads so they
show up differently, though some of those may be processes, on linux
there really aren't any threads as being separate from processes -- i.e.
threads, at the linux kernel level are built on processes AFAIK. Either
way, there can be a separation of what is executed based on what threads
are assigned what purposes. I'd be hesitant to label the exe/comm as
the only discriminator in an "arbitrary target environment". Certainly
it can be in some, but that doesn't mean it has to be sole discriminator
when different threads can be mapped to different functions in
1 starting binary.
In a similar way, coreutils, can be used as 1 library/binary where
functionality is determined by the invoking name. While coreutils uses
separate names for each function, there's nothing stopping creating
1 binary with all functions launched in separate threads launched out of
some shell performing diverse functions based on a thread ID or name.
Certainly it isn't the common case, but it would be a way for a hacker
to make their actions more opaque given current limitations. At the
same time, it might be the way to create some type of 'all-in-one' shell
that could be configured by runtime presence of loadable objects.
An audit system supporting appending of arbitrary data types could
support appending new data items/types as needed for extension. Such
was the Irix audit system that was ported to sgi's linux before the
project was cancelled. It had similar benefits to the various layers and
protocols that have been added on top of IPv4 networking, with wrappers
around the low-level IP layer being added as new protocols demanded.
Just saying, a case can be made for needed additions not originally
planned -- something that is almost always needed in time.
7:43 a.m.
On Mon, Nov 16, 2020 at 8:16 AM L. A. Walsh <lkml(a)tlinx.org> wrote:
On 2020/10/08 08:33, Lenny Bruzenak wrote:
> 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.
>
----
So, when different threads perform / execute different functionality
as loaded by a runtime loadable libraries, how is that discriminated
from the initially started program?
Often, programs with many threads will rename the threads so they
show up differently, though some of those may be processes, on linux
there really aren't any threads as being separate from processes -- i.e.
threads, at the linux kernel level are built on processes AFAIK. Either
way, there can be a separation of what is executed based on what threads
are assigned what purposes. I'd be hesitant to label the exe/comm as
the only discriminator in an "arbitrary target environment". Certainly
it can be in some, but that doesn't mean it has to be sole discriminator
when different threads can be mapped to different functions in
1 starting binary.
The most important thing to keep in mind is that all of the threads
inside a process share the same memory space. It is the lack of a
strong, enforceable boundary between threads which makes it difficult,
if not impossible, to view threads as individual entities from a
security perspective.
In a similar way, coreutils, can be used as 1 library/binary where
functionality is determined by the invoking name. While coreutils uses
separate names for each function, there's nothing stopping creating
1 binary with all functions launched in separate threads launched out of
some shell performing diverse functions based on a thread ID or name.
Certainly it isn't the common case, but it would be a way for a hacker
to make their actions more opaque given current limitations. At the
same time, it might be the way to create some type of 'all-in-one' shell
that could be configured by runtime presence of loadable objects.
First, and perhaps most importantly, see the earlier comments about
threads and the lack of strong boundaries inside a process. Second,
the busybox problem (different behavior based on the executable name)
is one of the many reasons why relying on executable names, pathnames,
etc. for identification of entities in a security policy is generally
ill advised.
--
paul moore
www.paul-moore.com
9:22 a.m.
On 2020/11/16 05:43, Paul Moore wrote:
The most important thing to keep in mind is that all of the threads
inside a process share the same memory space. It is the lack of a
strong, enforceable boundary between threads which makes it difficult,
if not impossible, to view threads as individual entities from a
security perspective.
---
Depends on how much your security policy relies on recognizing
abnormal behavior. If a program splits function across well defined
areas by a named thread, one may develop a baseline of "normal"
functionality associated with given threads. Determining that
a thread is operating outside it's normal range can allow for a
earlier detection and better monitoring of "safe" and/or secure
operation.
How programs operate, especially in regards to what work is
normal for a given thread can only be done with thread level
monitoring. While given threads _can_ access global-user memory,
that involves how they are coded or programmed to run. That, in
turn, can be used to help define boundaries and integrity levels
of various processes in a system.
For example, even though a logging thread might gather data
from other threads, knowing that it can only write to output
to specific configured destinations would allow swift detection
of aberrations.
1495
days inactive
1538
days old
linux-audit@lists.linux-audit.osci.io
9 comments
7 participants
participants (7)
-
L A Walsh -
L. A. Walsh
-
Lenny Bruzenak -
Natan Yellin -
Paul Moore -
Richard Guy Briggs -
Steve Grubb