On Wed, Aug 12, 2026 at 5:19 PM Steve Grubb <[email protected]> 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 <[email protected]> > wrote: > > > 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. > > > > 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
