[PATCH] audit: add task history record

[Tetsuo Handa]

On 2023/08/24 23:26, Paul Moore wrote:
> On Thu, Aug 24, 2023 at 9:47 AM Tetsuo Handa
> <penguin-kernel at 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.