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

[Steve Grubb <sgrubb@redhat.com>]

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@redhat.com> 
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'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