[PATCH 1/1] audit: make ADUITSYSCALL optional again

[PATCH 1/1] audit: make ADUITSYSCALL optional again

[Frederick Lawler]

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@cloudflare.com>
---
 init/Kconfig | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index af4c2f085455..2552918deb45 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -487,16 +487,21 @@ config AUDIT
 	help
 	  Enable auditing infrastructure that can be used with another
 	  kernel subsystem, such as SELinux (which requires this for
-	  logging of avc messages output).  System call auditing is included
-	  on architectures which support it.
+	  logging of avc messages output). Does not do system-call
+	  auditing without CONFIG_AUDITSYSCALL.
 
 config HAVE_ARCH_AUDITSYSCALL
 	bool
 
 config AUDITSYSCALL
-	def_bool y
+	bool "Enable system-call auditing support"
 	depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
+	default y
 	select FSNOTIFY
+	help
+	  Enable low-overhead system-call auditing infrastructure that
+	  can be used indepdently or with another kernel subsystem,
+	  such as SELiux.
 
 source "kernel/irq/Kconfig"
 source "kernel/time/Kconfig"
-- 
2.43.0

[RFC PATCH] audit: make ADUITSYSCALL optional again

[Frederick Lawler]

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@cloudflare.com>
---
 init/Kconfig | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index af4c2f085455..2552918deb45 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -487,16 +487,21 @@ config AUDIT
 	help
 	  Enable auditing infrastructure that can be used with another
 	  kernel subsystem, such as SELinux (which requires this for
-	  logging of avc messages output).  System call auditing is included
-	  on architectures which support it.
+	  logging of avc messages output). Does not do system-call
+	  auditing without CONFIG_AUDITSYSCALL.
 
 config HAVE_ARCH_AUDITSYSCALL
 	bool
 
 config AUDITSYSCALL
-	def_bool y
+	bool "Enable system-call auditing support"
 	depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
+	default y
 	select FSNOTIFY
+	help
+	  Enable low-overhead system-call auditing infrastructure that
+	  can be used indepdently or with another kernel subsystem,
+	  such as SELiux.
 
 source "kernel/irq/Kconfig"
 source "kernel/time/Kconfig"
-- 
2.43.0

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

[Paul Moore]

On Aug  8, 2025 Frederick Lawler <fred@cloudflare.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@cloudflare.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.

--
paul-moore.com

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

[Frederick Lawler]

Hi Paul,

On Wed, Aug 13, 2025 at 12:01:42PM -0400, Paul Moore wrote:
> On Aug  8, 2025 Frederick Lawler <fred@cloudflare.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@cloudflare.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