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

On Wed, Jul 29, 2026 at 2:11=E2=80=AFPM Steve Grubb <[email protected]> wro=
te:
> On Tuesday, July 28, 2026 4:35:20=E2=80=AFPM Eastern Daylight Time Paul M=
oore wrote:
> > On Jul 27, 2026 Ricardo Robaina <[email protected]> wrote:
> > > Modern mount tools (util-linux >=3D 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 b=
ut
> > > 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, paramete=
r
> > > name (key), parameter value, and aux parameter passed to fsconfig(2).
> > >
> > >  ----
> > >  type=3DSYSCALL : syscall=3Dfsconfig ... a1=3DFSCONFIG_SET_STRING ...
> > >  type=3DFSCONFIG : fs_cmd=3D1 fs_key=3Dsource fs_val=3D"tmpfs" fs_aux=
=3D0
> > >  ----
> > >  type=3DSYSCALL : syscall=3Dfsconfig ... a1=3DFSCONFIG_CMD_CREATE ...
> > >  type=3DFSCONFIG : fs_cmd=3D6 fs_key=3D(null) fs_val=3D(null) fs_aux=
=3D0
> > >  ----
> > >  type=3DSYSCALL : syscall=3Dfsconfig ... a1=3DFSCONFIG_SET_BINARY ...
> > >  type=3DFSCONFIG : fs_cmd=3D2 fs_key=3Dhidepid fs_val=3D"<binary>" fs=
_aux=3D4
> > >
> > > Link: https://github.com/linux-audit/audit-kernel/issues/153
> > > Acked-by: Christian Brauner <[email protected]>
> > > Signed-off-by: Ricardo Robaina <[email protected]>
> > > ---
> > > 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 =3D 0;
> > >
> > > +   const char *value_str =3D NULL;
> > >
> > >     struct fs_parameter param =3D {
> > >
> > >             .type   =3D fs_value_is_undefined,
> > >
> > > @@ -423,6 +425,7 @@ SYSCALL_DEFINE5(fsconfig,
> > >
> > >                     goto out_key;
> > >
> > >             }
> > >             param.size =3D strlen(param.string);
> > >
> > > +           value_str =3D param.string;
> > >
> > >             break;
> > >
> > >     case FSCONFIG_SET_BINARY:
> > >             param.type =3D fs_value_is_blob;
> > >
> > > @@ -432,6 +435,7 @@ SYSCALL_DEFINE5(fsconfig,
> > >
> > >                     ret =3D PTR_ERR(param.blob);
> > >                     goto out_key;
> > >
> > >             }
> > >
> > > +           value_str =3D "<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. T=
hat
> means we don't really have a use case. If, for example, someone decided t=
o
> 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 ha=
rd
> 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.

--=20
paul-moore.com