Identifying thread/process termination

[Paul Moore]

On Mon, Nov 16, 2020 at 8:16 AM L. A. Walsh <lkml at 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