Re: [PATCH] audit: do a quick exit when syscall number is invalid
On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote:
On 2022-04-02 08:06, CGEL wrote:
> 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> 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>
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?
I'm having a bit of trouble understanding what you've said above.
The kernel ultimately must protect itself from malice and mistakes, so
it must verify all data sent to it.
Userspace can help by knowing what that kernel policy is so it can avoid
violating that policy or provide useful feedback if it can't. Userspace
can be used to make things more efficient, but the kernel is the last
step for security.
If userspace and the kernel are mismatched or out of sync, then the
kernel enforces policy to protect itself.
Much appreciate for your interpretation. Have you get any idea of how
to solve the mismatched? From your viewpoint, I think it's better for
kernel to not handle syscall of syscall number<0, because it's invaild
of all arch, and has no value for attacker to probing for specific
syscall numbers.
> > > > > 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
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635