Re: [PATCH] audit: add task history record
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).