[PATCH] audit: add task history record

[Paul Moore]

On Sat, Aug 19, 2023 at 3:09 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2023/08/18 23:59, Paul Moore wrote:
> > 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.  It is my opinion that the audit patch
> > you have proposed here does not provide an audit administrator with
> > any new capabilities that they do not currently have as an option.
>
> Before explaining why an audit administrator cannot afford emulating
> this patch, I explain what this patch will do.
>
> There are three system calls for managing a process: fork()/execve()/exit().
>
>   https://I-love.SAKURA.ne.jp/tomoyo/fork.gif
>   https://I-love.SAKURA.ne.jp/tomoyo/execve.gif
>   https://I-love.SAKURA.ne.jp/tomoyo/exit.gif
>
> As a result, history of a process can be represented as a tree, where the
> root of the tree is the kernel thread which is started by the boot loader.
>
>   https://I-love.SAKURA.ne.jp/tomoyo/railway.gif
>
> This fundamental mechanism cannot be changed as long as Linux remains as a
> Unix-like OS. That is, adding this information will not cause what you call
> "the support burden" ...

Any new functionality added to the kernel, especially user visible
functionality or some sort of interface, adds a support burden.
Nothing is "free".

> > There are also concerns around field formatting, record length, etc.,
> > but those are secondary issues compared to the more important issue of
> > redundant functionality.
>
> If someone tries to emulate this patch, we need to be able to trace all
> fork()/execve()/exit() system calls. Or, the history tree will be broken.
>
> If an audit administrator tries to emulate this patch using system call
> auditing functionality, we need to make sure that
>
>   "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.

>   Rules for tracing fork()/execve()/exit() system calls must be enabled
>   when the kernel thread which is started by the boot loader starts.
>   How can we embed such system call auditing rules into the kernel and
>   tell whether to enable these rules using the kernel command line options?

I would boot the system with 'audit=1' on the kernel command line and
ensure that your desired audit rules are loaded as early in the boot
process as possible, before any long-running processes/daemons/logins
are started.  Honestly, that's simply a good best practice for anyone
who cares about maintaining a proper audit log, independent of the
specific use case here.

>   In order to avoid possibility of loosing fork()/execve()/exit() records,
>   auditd must not be stopped even temporarily. Who wants to enforce such
>   requirement in order to be able to obtain process history information?

A silly amount of work has gone into ensuring that the audit subsystem
in the kernel doesn't lose records when properly configured.  If you
haven't already, I would encourage you to read the auditctl(8) man
page and look for the parameters that adjust the audit backlog
configuration.

-- 
paul-moore.com