On 2023/08/16 3:44, Paul Moore wrote:
On Fri, Aug 11, 2023 at 6:58 AM Tetsuo Handa
<penguin-kernel(a)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?
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.
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.
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.
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.