[PATCH] audit: add task history record

[Paul Moore]

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.

> >                     and/or TOMOYO enabled and configured
>
> Wrong. Since not all LSM hooks allow sleeping, TOMOYO is unable to
> check sending signals. Also, TOMOYO is not using audit interface.

I said "audit and/or TOMOYO"; I believe the "and/or" is important.  If
I recall correctly, and perhaps I misunderstood you, you conceded that
a combination of audit *and/or* TOMOYO would solve this issue.

> >                                                          so I see no
> > reason why we want to merge this.
>
> This code makes it possible to record sending signals with TOMOYO-like context,
> and we can avoid assigning LSM ID for this code if we can merge this code as
> a part of audit.

If you want TOMOYO-like information, run TOMOYO.  If your preferred
distribution doesn't support TOMOYO, you need to either ask them to
support it, find a new distribution that does, or build your own
kernel.

> >                                    I understand your frustration that
> > TOMOYO is not enabled by your prefered distribution, but adding
> > additional (and arguably redundant code) code to the upstream kernel
> > is not a solution I am willing to support and maintain long term.
>
> Never a redundant code. Absolutely no reason we don't want to merge.

At this point in time, I obviously disagree.

> The only choice is which approach (a standalone LSM module or a part of audit)
> to go. Casey suggests this code as a part of audit. You must persuade Casey
> if you don't want this code as a part of audit.

To be very clear, it isn't my duty to persuade Casey about anything
(although if you've followed the LSM stacking saga you know I've
definitely tried on occasion! <g>).  My role here is to maintain the
audit subsystem and LSM layer (along with others which aren't relevant
here) to the best of my ability.  A big part of that is ensuring we
make "smart decisions" with respect to what code we merge as things
like new LSMs and new audit records are things that we have to support
*forever*.  Because of this rather extreme support burden I need to
make sure that we aren't making our jobs (current developers, current
maintainers, and those that will follow us) more difficult than
absolutely necessary.  From my current perspective, the benefits of
this patch, both in terms of unique functionality and durability of
the design/code, are not enough to outweigh the support burden.

-- 
paul-moore.com