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

[Ricardo Robaina]

On Wed, Aug 12, 2026 at 5:19 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
>
> On Wednesday, August 12, 2026 12:03:17 PM Eastern Daylight Time Paul Moore
> wrote:
> > On Wed, Aug 12, 2026 at 10:40 AM Ricardo Robaina <rrobaina@xxxxxxxxxx>
> wrote:
> > > On Tue, Jul 28, 2026 at 6:22 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > On Mon, Jul 13, 2026 at 1:00 PM 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 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@xxxxxxxxxx>
> > > > > ---
> > > > >
> > > > >  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.
> >
> > Thanks Ricardo, I think this would be a great improvement!
> >
> > I'm particularly curious to see what old/existing userspace tooling
> > will do if we add the last two syscall arguments immediately after the
> > first four.
>
> It would ignore them. During search, it grabs a0 and a1, then skips to ppid.
> In the output phase, it should also ignore them since there's no code to
> interpret them.
>
> > If we have to we can add them to the end, but if it
> > doesn't break anything it would be preferable to add them inline with
> > the other parameters.
>
> I'd also prefer inline. That's the most natural view.
>
> -Steve
>
>

Thanks Paul and Steve, I agree that inline would be better as well.

I spent the afternoon working on this and already have a working
draft. I'll do some extra tests and review it, but I believe I'll be
able to post it over the next few days.

-Ricardo