Re: [PATCH] audit: add task history record
On Sat, Aug 19, 2023 at 3:09 AM Tetsuo Handa
<penguin-kernel(a)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