Re: [PATCH v2] audit: add FSCONFIG auxiliary record to log filesystem configuration

[Ricardo Robaina]

On Wed, Jul 29, 2026 at 5:33 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Jul 29, 2026 at 2:11 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
> > On Tuesday, July 28, 2026 4:35:20 PM Eastern Daylight Time Paul Moore wrote:
> > > On Jul 27, 2026 Ricardo Robaina <rrobaina@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > > Signed-off-by: Ricardo Robaina <rrobaina@xxxxxxxxxx>
> > > > ---
> > > > 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.
>
> Let's just log the binary data.

Good. I'll be sending a new version shortly. Thank you all!

>
> --
> paul-moore.com
>

-Ricardo