Re: [PATCH v2] TaskTracker : Simplified thread information tracker.

[Paul Moore <paul@paul-moore.com>]

On Tue, Aug 8, 2023 at 6:07 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2023/08/08 5:13, Paul Moore wrote:
> > On Mon, Aug 7, 2023 at 3:03 PM Steve Grubb <sgrubb@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@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.

What makes you think your distribution of choice would enable this new
LSM?  I'm sorry, but this sounds like more of an issue with the
choices made by a distro rather than something missing upstream.

-- 
paul-moore.com

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