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). -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit