On Tue, Aug 8, 2023 at 6:07 AM Tetsuo Handa <penguin-ker...@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 <sgr...@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-ker...@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
