Re: Identifying thread/process termination

["L. A. Walsh" <lkml@tlinx.org>]

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.


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