Identifying thread/process termination
Repost from right address.
Quoted 11 lines · Lenny Bruzenak
Quoted 7 lines · Paul Moore
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.
Quoted 2 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 50 lines · L. A. Walsh
Repost from right address.
Quoted 11 lines · Lenny Bruzenak
On 10/7/20 7:27 PM, Paul Moore wrote:
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
Just saying, a case can be made for needed additions not originally planned -- something that is almost always needed in time.
Sorry for the belated reply. Good points.
The main focus (of an audit system) is on being able to prove accountability. Because threads cannot be initiated directly by a person, only the parent executable, this is as much as is reasonably required, currently.
Sure, technically all you say is pretty reasonable, but using your example of RTLs, extend that to those entities as well. You often don't have insight into their internals except via the audit trail (syscalls)
- and you know the launched executable.
Threads/libraries/executables don't face consequences, people do. So until a person (or systemd/cron/...) can launch a thread on its own, it doesn't make a lot of difference, as it is identifiable to the parent process, which so far, gives us enough traceability.
The rules need to be such that for a given system security stance, Who launched Which When causing What is the main focus. Definitely the more relevant information the better from a forensics perspective. However, I'd submit that having the thread ID would not lend much to an investigation. Probably not even in a subsequent attempt to recreate the issue you would be investigating. But it is possible I'm overlooking something. As Paul said in the OP, there isn't that much boundary between threads instantiated from a common parent process, so examining the process entity as a whole is what would need to happen.
Your point about differently-named executables being the same is a good one, sure there are lots of executables hard-linked to the same code, look at /sbin/lvm - I see :
% ls -al /sbin | grep "\-> lvm" | wc -l
43
Doesn't really matter; you still should have the syscall records you need, surrounded by all the relevant facts (auid, date/time, executable name, etc., etc.). The thread ID (maybe really even the parent process ID, except possibly for inclusion with other events, but that's a stretch) is irrelevant AFAIK.
If the current granularity proves inadequate to achieve the auditing goals, then IMHO this would need to be revisited, because I agree, as I'm sure most everyone would, with your final statement - things change.
V/R,
LCB
Signature · 7 lines
Lenny Bruzenak MagitekLTD -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit