On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote:
> On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote:
> > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote:
> > >
> > > If audit is not generating SYSCALL records, even for invalid/ENOSYS
> > > syscalls, I would consider that a bug which should be fixed.
> >
> > If we fix this bug, do you think audit invalid/ENOSYS syscalls better
> > be forcible or be a rule that can be configure? I think configure is
> > better.
> 
> It isn't clear to me exactly what you are asking, but I would expect
> the existing audit syscall filtering mechanism to work regardless if
> the syscall is valid or not.  

Thanks, I try to make it more clear. We found that auditctl would only
set rule with syscall number (>=0 && <2047). So if userspace using
syscall whose number is (<0 || >=2047), there seems no meaning for
kernel audit to handle it, since this kind of syscall will never hit
any audit rule(this rule could not be set by auditctl).

By the way it's a little strange for auditctl(using libaudit.c) to limit
syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially
we know NR_syscalls is the real limit in kernel, you can see how other
kernel code to the similar thing in ftrace_syscall_enter():

	static void ftrace_syscall_enter(void *data, struct pt_regs
	*regs, long id)
	{
		...
		syscall_nr = trace_get_syscall_nr(current, regs);
		if (syscall_nr < 0 || syscall_nr >= NR_syscalls)
			return;
		...
	}

Thanks.
> Beware that there are some limitations
> to the audit syscall filter, which are unfortunately baked into the
> current design/implementation, which may affect this to some extent.
> 
> -- 
> paul-moore.com