[PATCH] audit: add task history record

[Tetsuo Handa]

On 2023/08/23 23:48, Paul Moore wrote:
> We've already discussed this both from a kernel load perspective (it
> should be able to handle the load, if not that is a separate problem
> to address) as well as the human perspective (if you want auditing,
> you need to be able to handle auditing).

No. You haven't shown us audit rules that can satisfy requirements shown below.

  (1) Catch _all_ process creations (both via fork()/clone() system calls and
      kthread_create() from the kernel), and duplicate the history upon process
      creation.

  (2) Catch _all_ execve(), and update the history upon successful execve().

  (3) Catch _all_ process terminations (both exit()/exit_group()/kill() system
      calls and internal reasons such as OOM killer), and erase the history upon
      process termination.

  (4) Do the above things without asking administrators to become a specialist of
      system management and without asking administrators to drastically change
      system configurations and without consuming too much CPU and storage.

We know we can't satisfy requirements shown above using audit rules. That's why
this patch maintains process history information without using audit rules.

> 
> Tetsuo, as should be apparent at this point, I'm finding your
> arguments unconvincing at best, and confusing at worst.  If you or
> someone else wants to take a different approach towards arguing for
> this patch I'll entertain the discussion further, but please do not
> reply back with the same approach; it simply isn't constructive at
> this point.

Although it will be nice if we can fetch this process history information
directly from "current", I can live with fetching this process history
information from "current->security" (that is, moving what you call "the
support burden" from audit subsystem to LSM module authors).