[PATCH v2] TaskTracker : Simplified thread information tracker.

Tetsuo Handa penguin-kernel at I-love.SAKURA.ne.jp
Tue Aug 8 10:07:10 UTC 2023


On 2023/08/08 5:13, Paul Moore wrote:
> On Mon, Aug 7, 2023 at 3:03 PM Steve Grubb <sgrubb at redhat.com> wrote:
>> On Monday, August 7, 2023 2:53:40 PM EDT Paul Moore wrote:
>>> On Sun, Aug 6, 2023 at 9:05 AM Tetsuo Handa
>>>
>>> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>>>> When an unexpected system event occurs, the administrator may want to
>>>> identify which application triggered the event. For example, unexpected
>>>> process termination is still a real concern enough to write articles
>>>> like https://access.redhat.com/solutions/165993 . TaskTracker is a
>>>> trivial LSM module which emits TOMOYO-like information into the audit
>>>> logs for better understanding of unexpected system events.
>>>
>>> Help me understand why all of this information isn't already available
>>> via some combination of Audit and TOMOYO, or simply audit itself?
>>
>> Usually when you want this kind of information, you are investigating an
>> incident. You wouldn't place a syscall audit for every execve and then
>> reconstruct the call chain from that. In the case of long running daemons,
>> the information could have been rotated away. But typically you want to see
>> what the entry point is. A sudden shell from bind would be suspicious while a
>> shell from sshd is not.
> 
> Once again, why not use the existing audit and/or TOMOYO capabilities.
> 

Can't, for Fedora/RHEL does not enable TOMOYO.
I need a way that can be used by RHEL users running with selinux=0.

This history information is expected to become available for those who
might want to investigate unexpected system events, but should not become
unconditionally available for those who do not want to bloat audit logs.
Switching via lsm=tt is a handy way for satisfying both.



More information about the Linux-audit mailing list