[PATCH] audit: add task history record

[Tetsuo Handa]

On 2023/08/22 1:35, Paul Moore wrote:
>>   "auditctl -D" must not clear rules for tracing fork()/execve()/exit()
>>   system calls. This is impossible because this change will break userspace
>>   programs expecting that "auditctl -D" clears all rules.
> 
> It's a good thing that 'audtictl -d ...' exists so that one can
> selectively delete audit rules from the kernel.  If someone wants to
> preserve specific audit rules, that is the way to do it; 'auditctl -D'
> is a very coarse tool and not something that is likely very useful for
> users with strict auditing requirements.

In most systems, "auditctl -D" is the first command done via /etc/audit/audit.rules file.
You are asking all administrators who want to emulate this patch's functionality using
auditd to customize that line. We can't afford asking such administrators to become
specialist of strict auditing configurations, as well as we can't afford asking
every administrator to become specialist of strict SELinux policy configurations.

Like Steve Grubb mentions, technically possible and practically affordable are
different. The audit subsystem could handle the load, but the system administrator 
can't handle the load. That's why I said

  That is a "No LSM modules other than SELinux is needed because SELinux can do
  everything" assertion.

and your response

  Except we are not talking SELinux or LSMs here, we are talking about
  audit and the audit subsystem is very different from the LSM layer.
  The LSM layer is designed to be pluggable with support for multiple
  individual LSMs, whereas the audit subsystem is designed to support a
  single audit implementation.

is totally missing the point.

For example, doing

  auditctl -a exit,always -F arch=b64 -S exit,exit_group

(in order to allow userspace daemon which tries to emulate this patch's
functionality) will let auditd to generate process termination logs via exit()
system call. This command alone can generate too much stress on a busy system
(performance DoS and storage DoS). And moreover, this command will not let
auditd to generate process termination logs via kill() system call.

  kill -9 $$

Auditing kill system call may generate more stress than auditing exit system call.
Too much noisy logs for catching the exact one event we want to know.

Also, despite too much logs, system calls are not the only source of sending
signals. There are signals delivered without security checks via LSM modules.



The requirements for emulating functionality provided by this patch will be

  (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.

. Simply we can't emulate functionality provided by this patch using audit rules.