On Wed, Jul 29, 2026 at 2:11 PM Steve Grubb <[email protected]> wrote: > On Tuesday, July 28, 2026 4:35:20 PM Eastern Daylight Time Paul Moore wrote: > > On Jul 27, 2026 Ricardo Robaina <[email protected]> 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 <[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 = 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. -- paul-moore.com
