public inbox for audit@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Frederick Lawler <fred@cloudflare.com>, Eric Paris <eparis@redhat.com>
Cc: audit@vger.kernel.org, kernel-team@cloudflare.com,
	linux-kernel@vger.kernel.org,
	Frederick Lawler <fred@cloudflare.com>
Subject: Re: [PATCH 1/1] audit: make ADUITSYSCALL optional again
Date: Wed, 13 Aug 2025 12:01:42 -0400	[thread overview]
Message-ID: <b7fae70a87b4fe937607e5e3215397bc@paul-moore.com> (raw)
In-Reply-To: <20250808194034.3559323-1-fred@cloudflare.com>

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

  parent reply	other threads:[~2025-08-13 16:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-08 19:40 [PATCH 1/1] audit: make ADUITSYSCALL optional again Frederick Lawler
2025-08-08 19:40 ` [RFC PATCH] " Frederick Lawler
2025-08-13 16:01 ` Paul Moore [this message]
2025-08-13 20:39   ` [PATCH 1/1] " Frederick Lawler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b7fae70a87b4fe937607e5e3215397bc@paul-moore.com \
    --to=paul@paul-moore.com \
    --cc=audit@vger.kernel.org \
    --cc=eparis@redhat.com \
    --cc=fred@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox