On 2023/08/24 23:26, Paul Moore wrote: > On Thu, Aug 24, 2023 at 9:47 AM Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: >> On 2023/08/24 22:39, Tetsuo Handa wrote: >>>>> (1) Catch _all_ process creations (both via fork()/clone() system calls >>>>> and >>>>> kthread_create() from the kernel), and duplicate the history upon >>>>> process >>>>> creation. >>>> >>>> Create an audit filter rule to record the syscalls you are interested >>>> in logging. >>> >>> I can't interpret what you are talking about. Please show me using command >>> line. >> >> I'm not interested in logging the syscalls just for maintaining process >> history >> information. > > That's unfortunate because I'm not interested in merging your patch > when we already have an audit log which can be used to trace process > history information. >
It is unfortunate that you continue ignoring the How can auditd generate logs that are not triggered via syscalls? line. I know how to configure syscall rules using "-S" option. But I do not know how to configure non syscall rules (such as process creation via kthread_create(), process termination due to tty hangup or OOM killer). It is unfortunate that you continue ignoring the What this patch does is to allow people do like printk("[%s] some msg comes here\n", current->comm_history); for giving hints for identifying a process more precisely. That is, users of this information is not limited to audit. For example, an LSM module can use this information, an audit record can use this information, a SystemTap script can use this information, and so on... block. The logs generated via system call auditing is just an example. I want to use this information from e.g. SystemTap scripts, but you care about only system call auditing. There are cases where the logs generated via system call auditing can solve problems. But there are cases we need to hook different locations using e.g. SystemTap scripts in order to catch the event. I repeat: The auditd is not capable of generating _all_ records needed for maintaining this information. The logs generated via system call auditing is just an example user of this information. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit