Re: [PATCH] audit: add task history record

[Paul Moore <paul@paul-moore.com>]

On Wed, Aug 23, 2023 at 10:18 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> 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.

If an administrator/user needs to configure the audit subsystem to do
something, removing one line in a configuration file seems like a very
reasonable thing to do.  You can expect the default configuration of
every Linux distribution to fit every conceivable use case.

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

If an administrator/user wants this type of information in their audit
logs they need to be prepared to handle that information.

> That's why I said
>
>   That is a "No LSM modules other than SELinux is needed because SELinux can do
>   everything" assertion.

What?  That doesn't make any sense following what you said above.
You're starting to cherry pick quotes and apply them out of context,
which only hurts your argument further.

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

It makes perfect sense in the original context, see my comment above,
and perhaps go re-read that original email.

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

However, in this very same email, a few paragraphs above you conceded
that "The audit subsystem could handle the load".

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

We've already discussed this both from a kernel load perspective (it
should be able to handle the load, if not that is a separate problem
to address) as well as the human perspective (if you want auditing,
you need to be able to handle auditing).

Tetsuo, as should be apparent at this point, I'm finding your
arguments unconvincing at best, and confusing at worst.  If you or
someone else wants to take a different approach towards arguing for
this patch I'll entertain the discussion further, but please do not
reply back with the same approach; it simply isn't constructive at
this point.

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit