[PATCH] audit: add task history record

[Tetsuo Handa]

On 2023/08/22 1:04, Serge E. Hallyn wrote:
> On Sat, Aug 19, 2023 at 04:09:46PM +0900, Tetsuo Handa wrote:
>> Anyway, enabling TOMOYO in Fedora/RHEL kernels won't solve the problem
>> this patch is trying to solve, for TOMOYO cannot utilize TOMOYO's process
>> history information because LSM hook for sending signals does not allow
>> TOMOYO to sleep...
> 
> Hang on a tick - I think perhaps you should have led with this.  The
> main argument against this has been (iiuc) that it is a subset of
> tomoyo functionality.  In that case, I'm on the fence about whether it
> should be included.
> 
> But here you say that tomoyo cannot do this.  If that's the case, and
> this is simply completely new functionality, that changes things.

This information is duplicated upon fork() and updated upon execve().
That is how TOMOYO defines TOMOYO's process history information.
Therefore, I'm saying "TOMOYO-like task history information".
But this information provided by this patch is different from TOMOYO's
process history information provided by TOMOYO in two ways.

One is that TOMOYO embeds pathname of a program passed to execve() into
TOMOYO's task history information because it is used for describing access
control rules, whereas this patch embeds comm name and pid and time of execve()
into task history information because it is used for helping administrators
understand system events.

The other is that TOMOYO can check and generate logs with TOMOYO's task history
information for only operations that can sleep (e.g. open()/execve()), whereas
this patch can check and generate logs with task history information for both
sleepable (e.g. open()/execve()) and non-sleepable (e.g. kill()) operations.

Since one of use cases of this task history information is to identify who sent
a signal that caused an unexpected process termination, TOMOYO cannot be do it.

Also, system calls are not the only source of sending signals. There are signals
delivered without security checks via LSM modules. In that case, inserting a
SystemTap script helps catching such signals. But SystemTap scripts are loaded
too late to emulate task history information from boot.