[PATCH] audit: add task history record

[Paul Moore]

On Fri, Aug 18, 2023 at 6:30 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2023/08/16 22:53, Paul Moore wrote:
> > On Wed, Aug 16, 2023 at 6:10 AM Tetsuo Handa
> > <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >> On 2023/08/16 3:44, Paul Moore wrote:
> >>> On Fri, Aug 11, 2023 at 6:58 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 .
> >>>>
> >>>> This patch adds a record which emits TOMOYO-like task history information
> >>>> into the audit logs for better understanding of unexpected system events.
> >>>>
> >>>>   type=UNKNOWN[1340] msg=audit(1691750738.271:108): history="name=swapper/0;pid=1;start=20230811194329=>name=init;pid=1;start=20230811194343=>name=systemd;pid=1;start=20230811194439=>name=sshd;pid=3660;start=20230811104504=>name=sshd;pid=3767;start=20230811104535"
> >>>
> >>> While I respect your persistence, we've talked about this quite a bit
> >>> already in other threads.  What you are trying to do is already
> >>> possible with audit
> >>
> >> How?
> >
> > If you configure audit to record exec() and friends you should have a
> > proper history of the processes started on the system.
>
> That is a "No LSM modules other than SELinux is needed because SELinux can do
> everything" assertion.

Except we are not talking SELinux or LSMs here, we are talking about
audit and the audit subsystem is very different from the LSM layer.
The LSM layer is designed to be pluggable with support for multiple
individual LSMs, whereas the audit subsystem is designed to support a
single audit implementation.  It is my opinion that the audit patch
you have proposed here does not provide an audit administrator with
any new capabilities that they do not currently have as an option.

There are also concerns around field formatting, record length, etc.,
but those are secondary issues compared to the more important issue of
redundant functionality.

> People propose different approaches/implementations because
> they can't afford utilizing/configuring existing approaches/implementations.

>From what I've seen, both in this thread as well as the other related
threads from you, these recent efforts are due to a lack of TOMOYO
support in mainstream Linux distributions.  My advice is to stop
trying to duplicate the TOMOYO functionality in other subsystems/LSMs
and start working with the distributions to better understand why they
are not supporting TOMOYO.  I believe that if you can determine why
the distributions are not enabling TOMOYO, you should be able to
develop a plan to address those issues and eventually gain
distribution support for TOMOYO.  I understand that such an approach
will likely be time consuming and difficult, but I think that is your
best option for success.

> Your assertion is a fatal problem for merging "Re: [PATCH v13 00/11] LSM: Three basic syscalls"
> at https://lkml.kernel.org/r/CAHC9VhQ4ttkSLTBCrXNZSBR1FP9UZ_gUHmo0BS37LCdyBmUeyA@mail.gmail.com .
>
> Please please allow LSM modules like https://lkml.kernel.org/r/41d03271-ff8a-9888-11de-a7f53da47328@I-love.SAKURA.ne.jp
> to obtain a stable LSM ID

We've already discussed that in the TaskTracker thread.

> if you don't want to support something that possibly have an alternative.

We've already upstreamed an alternative approach to TaskTracker: TOMOYO.

-- 
paul-moore.com