From: Paul Moore <paul@paul-moore.com>
To: Ricardo Robaina <rrobaina@redhat.com>,
audit@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: eparis@redhat.com, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, sgrubb@redhat.com, rbriggs@redhat.com,
Ricardo Robaina <rrobaina@redhat.com>
Subject: Re: [PATCH v2] audit: add FSCONFIG auxiliary record to log filesystem configuration
Date: Tue, 28 Jul 2026 16:35:20 -0400 [thread overview]
Message-ID: <4fad20e4737ff546ce0a822d9522adac@paul-moore.com> (raw)
In-Reply-To: <20260727173710.964626-1-rrobaina@redhat.com>
On Jul 27, 2026 Ricardo Robaina <rrobaina@redhat.com> wrote:
>
> Modern mount tools (util-linux >= 2.39.1) use the new mount API
> (fsopen, fsconfig, fsmount, move_mount) instead of the legacy mount(2)
> syscall. The generic SYSCALL audit record logs the fsconfig syscall but
> does not capture the configuration parameters, creating an audit gap for
> critical mount information such as the device being mounted.
>
> Add an FSCONFIG auxiliary record that logs the command type, parameter
> name (key), parameter value, and aux parameter passed to fsconfig(2).
>
> ----
> type=SYSCALL : syscall=fsconfig ... a1=FSCONFIG_SET_STRING ...
> type=FSCONFIG : fs_cmd=1 fs_key=source fs_val="tmpfs" fs_aux=0
> ----
> type=SYSCALL : syscall=fsconfig ... a1=FSCONFIG_CMD_CREATE ...
> type=FSCONFIG : fs_cmd=6 fs_key=(null) fs_val=(null) fs_aux=0
> ----
> type=SYSCALL : syscall=fsconfig ... a1=FSCONFIG_SET_BINARY ...
> type=FSCONFIG : fs_cmd=2 fs_key=hidepid fs_val="<binary>" fs_aux=4
>
> Link: https://github.com/linux-audit/audit-kernel/issues/153
> Acked-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Ricardo Robaina <rrobaina@redhat.com>
> ---
> Changes in v2:
> - Fixed null-check for fs_key field.
> - Clarified trimmed SYSCALL output in commit message examples.
>
> fs/fsopen.c | 7 +++++++
> include/linux/audit.h | 13 +++++++++++++
> include/uapi/linux/audit.h | 1 +
> kernel/auditsc.c | 27 +++++++++++++++++++++++++++
> 4 files changed, 48 insertions(+)
>
> diff --git a/fs/fsopen.c b/fs/fsopen.c
> index ae19e5136598..9b3c02f59df4 100644
> --- a/fs/fsopen.c
> +++ b/fs/fsopen.c
> @@ -15,6 +15,7 @@
> #include <linux/namei.h>
> #include <linux/file.h>
> #include <uapi/linux/mount.h>
> +#include <linux/audit.h>
> #include "internal.h"
> #include "mount.h"
>
> @@ -357,6 +358,7 @@ SYSCALL_DEFINE5(fsconfig,
> struct fs_context *fc;
> int ret;
> int lookup_flags = 0;
> + const char *value_str = NULL;
>
> struct fs_parameter param = {
> .type = fs_value_is_undefined,
> @@ -423,6 +425,7 @@ SYSCALL_DEFINE5(fsconfig,
> goto out_key;
> }
> param.size = strlen(param.string);
> + value_str = param.string;
> break;
> case FSCONFIG_SET_BINARY:
> param.type = fs_value_is_blob;
> @@ -432,6 +435,7 @@ SYSCALL_DEFINE5(fsconfig,
> ret = PTR_ERR(param.blob);
> goto out_key;
> }
> + value_str = "<binary>";
Is there a reason why we're not logging the binary data? We might want
to impose a size limit to truncate the logged data (although we have
provisions to log rather large binary chunks), but I don't see a reason
why we couldn't log the binary data as a hex string.
> break;
> case FSCONFIG_SET_PATH_EMPTY:
> lookup_flags = LOOKUP_EMPTY;
> @@ -445,6 +449,7 @@ SYSCALL_DEFINE5(fsconfig,
> }
> param.dirfd = aux;
> param.size = strlen(param.name->name);
> + value_str = param.name->name;
> break;
> case FSCONFIG_SET_FD:
> param.type = fs_value_is_file;
> @@ -458,6 +463,8 @@ SYSCALL_DEFINE5(fsconfig,
> break;
> }
>
> + audit_log_fsconfig(cmd, param.key, value_str, aux);
> +
> ret = mutex_lock_interruptible(&fc->uapi_mutex);
> if (ret == 0) {
> ret = vfs_fsconfig_locked(fc, cmd, ¶m);
...
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 6610e667c728..fefc5c5dd4aa 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2882,6 +2882,33 @@ void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
> }
> EXPORT_SYMBOL_GPL(__audit_log_nfcfg);
>
> +void __audit_log_fsconfig(unsigned int cmd, const char *key,
> + const char *value, int aux)
> +{
> + struct audit_buffer *ab;
> +
> + ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_FSCONFIG);
> + if (!ab)
> + return;
> +
> + audit_log_format(ab, "fs_cmd=%u", cmd);
> + audit_log_format(ab, " fs_key=");
Calling into audit_log_format() is expensive due to the string
processing, we should combine this into a single audit_log_format()
call:
audit_log_format(ab, "fs_cmd=%u fs_key=", cmd);
> + if (key)
> + audit_log_untrustedstring(ab, key);
> + else
> + audit_log_format(ab, "(null)");
> +
> + audit_log_format(ab, " fs_val=");
> + if (value)
> + audit_log_untrustedstring(ab, value);
> + else
> + audit_log_format(ab, "(null)");
> +
> + audit_log_format(ab, " fs_aux=%d", aux);
> +
> + audit_log_end(ab);
> +}
> +
> static void audit_log_task(struct audit_buffer *ab)
> {
> kuid_t auid, uid;
> --
> 2.53.0
--
paul-moore.com
next prev parent reply other threads:[~2026-07-28 20:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 17:37 Ricardo Robaina
2026-07-28 20:33 ` Richard Guy Briggs
2026-07-28 20:35 ` Paul Moore [this message]
2026-07-29 18:11 ` Steve Grubb
2026-07-29 20:33 ` Paul Moore
2026-08-20 12:41 ` Ricardo Robaina
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=4fad20e4737ff546ce0a822d9522adac@paul-moore.com \
--to=paul@paul-moore.com \
--cc=audit@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=eparis@redhat.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rbriggs@redhat.com \
--cc=rrobaina@redhat.com \
--cc=sgrubb@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®