From: Steve Grubb <sgrubb@redhat.com>
To: Ricardo Robaina <rrobaina@redhat.com>,
audit@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Paul Moore <paul@paul-moore.com>
Cc: eparis@redhat.com, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, rbriggs@redhat.com,
Ricardo Robaina <rrobaina@redhat.com>
Subject: Re: [PATCH v2] audit: add FSCONFIG auxiliary record to log filesystem configuration
Date: Wed, 29 Jul 2026 14:11:19 -0400 [thread overview]
Message-ID: <-GF9cdtWTQSigd6gY6zWOw@redhat.com> (raw)
In-Reply-To: <4fad20e4737ff546ce0a822d9522adac@paul-moore.com>
On Tuesday, July 28, 2026 4:35:20 PM Eastern Daylight Time Paul Moore wrote:
> 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.
I did a search for any user of this. There are no known consumers. Last
February, fsparam_blob() / fs_param_is_blob parser support was removed. That
means we don't really have a use case. If, for example, someone decided to
use this API to insert a private key used for decryption or something, we
probably don't want that in logs. So, without an actual use case, it's hard
to say if logging this would be a liability or something needed. But yes, it
could be done with the hex string encoding if required.
-Steve
> > 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;
>
> --
> paul-moore.com
next prev parent reply other threads:[~2026-07-29 18:11 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
2026-07-29 18:11 ` Steve Grubb [this message]
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=-GF9cdtWTQSigd6gY6zWOw@redhat.com \
--to=sgrubb@redhat.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=paul@paul-moore.com \
--cc=rbriggs@redhat.com \
--cc=rrobaina@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®