linux-kernel - Re: [PATCH 1/1] audit: make ADUITSYSCALL optional again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aJz4FOOy8eYO6OTN@CMGLRV3>
Date: Wed, 13 Aug 2025 15:39:48 -0500
From: Frederick Lawler <fred@...udflare.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Eric Paris <eparis@...hat.com>, audit@...r.kernel.org,
	kernel-team@...udflare.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] audit: make ADUITSYSCALL optional again

Hi Paul,

On Wed, Aug 13, 2025 at 12:01:42PM -0400, Paul Moore wrote:
> On Aug  8, 2025 Frederick Lawler <fred@...udflare.com> wrote:
> > 
> > Since the introduction of commit cb74ed278f80 ("audit: always enable
> > syscall auditing when supported and audit is enabled"), eBPF
> > technologies are being adopted to track syscalls for auditing purposes.
> > Those technologies add an additional overhead ontop of AUDITSYSCALL.
> > Additionally, AUDIT infrastructure has expanded to include INTEGRITY which
> > offers some advantages over eBPF technologies, such as early-init/boot
> > integrity logs with. Therefore, make ADUITSYSCALL optional
> > again, but keep it default y.
> > 
> > Signed-off-by: Frederick Lawler <fred@...udflare.com>
> > ---
> >  init/Kconfig | 11 ++++++++---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
>  
> Generally speaking the less Kconfig knobs the better; it tends to
> complicate things and for those that rely on distro kernels, there is
> always at least one group that is going to be upset about the Kconfig
> knob being set "wrong".  In my ideal world, CONFIG_AUDITSYSCALL wouldn't
> exist at all, but sadly not all arches have the necessary support to
> do that at the moment, so CONFIG_AUDITSYSCALL remains a necessary evil.
> 
> Thank you for the patch, but IMO this is not the direction we want to
> go with audit.
> 

Thanks for the response. I think setting the filters to never would be
OK, but doesn't hurt to try to see if it's worth squeezing out the
remaining usages.

> --
> paul-moore.com

PS. I'll be sure to use b4 next time for a
submission. 

Best, Fred