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

On Tue, Jul 28, 2026 at 6:22 PM Paul Moore <[email protected]> wrote:
>
> On Mon, Jul 13, 2026 at 1:00 PM 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 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 <[email protected]>
> > ---
> >  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'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