On Mon, Nov 16, 2020 at 8:16 AM L. A. Walsh <l...@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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
