Re: [PATCH] audit: do a quick exit when syscall number is invalid

On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > 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(a)gmail.com&gt; 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) ... > > That is exactly why I wrote the warning below in my response ... > I think the question is more clear now. 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and syscall with number 3000 are both invalid syscall. But 2000 can be set by auditctl, and 3000 cannot be set by auditctl. A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall See this patch. If we want audit invalid syscall as you said before. libaudit.c should not do the forbidden, auditctl should allow setting syscall rule with 'any' number. So do you think we should fix libaudit.c?

> > > > 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