Re: [PATCH] audit: add task history record
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.