Re: [PATCH] audit: add MOVE_MOUNT auxiliary record to log mount relocation

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday, August 12, 2026 10:39:52 AM Eastern Daylight Time Ricardo 
Robaina wrote:
> On Tue, Jul 28, 2026 at 6:22 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, Jul 13, 2026 at 1:00 PM 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 move_mount syscall
> > > but does not capture the flags argument, creating an audit gap for
> > > mount relocation operations.
> > > 
> > > Add a MOVE_MOUNT auxiliary record that logs the flags argument passed
> > > to move_mount(2). Pathnames and file descriptors are captured through
> > > existing PATH records and SYSCALL record arguments.
> > > 
> > >  ----
> > >  type=PATH : item=0 name=/mnt/test_src inode=1 dev=00:41 ...
> > >  type=SYSCALL : arch=x86_64 syscall=move_mount ...
> > >  type=MOVE_MOUNT : fs_flags=0x4
> > >  ----
> > >  type=PATH : item=0 name=/mnt/test_dst inode=27460862 dev=fc:00 ...
> > >  type=SYSCALL : arch=x86_64 syscall=move_mount ...
> > >  type=MOVE_MOUNT : fs_flags=0x4
> > > 
> > > Link: https://github.com/linux-audit/audit-kernel/issues/152
> > > Link: https://github.com/linux-audit/audit-kernel/issues/153
> > > Signed-off-by: Ricardo Robaina <rrobaina@redhat.com>
> > > ---
> > > 
> > >  fs/namespace.c             |  3 +++
> > >  include/linux/audit.h      | 10 ++++++++++
> > >  include/uapi/linux/audit.h |  1 +
> > >  kernel/auditsc.c           | 13 +++++++++++++
> > >  4 files changed, 27 insertions(+)
> 
> Thanks for reviewing this patch, Paul!
> 
> > This is because we only log the first four syscall parameters,
> > correct?  To put this another way, if we logged all six syscall
> > parameters this wouldn't be an issue, yes?
> 
> Yes, that's correct.

I've been aiming to reply to this and lost the original...in the case of 
mmap, yes. If we had just 5 of the passed values, we would not need a 
supplemental record just to record the fd.

However, in many other syscalls, we only have pointers. Sometimes syscalls 
are designed to pass a structure with config items where some are security 
relevant. In those cases having all the args doesn't help and we still need 
the supplemental record.

-Steve

> > I'm aware of the argument for only logging the first four parameters,
> > but I've always thought it was a rather foolish decision.  Perhaps now
> > is the time to spend to investigate adding those two missing
> > parameters to the SYSCALL record so we don't have to worry about hacky
> > workarounds like this (to be clear, I know this hacky workaround isn't
> > your fault, you are just trying to make the best of a kludgy thing
> > <g>).
> 
> I completely agree that's the right thing to do, and I'm happy to hear
> that you'd be open to it.
> 
> I did a quick check and there are 100+ syscalls (~18% of the total)
> with more than 4 arguments
>  --around 67 of which pass audit-relevant scalars (flags, sizes,
> modes) in the 5th or 6th position
> that are currently lost.
> 
> I'll look into it. Please disregard this patch in the meantime.
> 
> > --
> > paul-moore.com
> 
> -Ricardo