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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Apr 2022 11:58:50 -0400
From:   Richard Guy Briggs <rgb@...hat.com>
To:     CGEL <cgel.zte@...il.com>
Cc:     Paul Moore <paul@...l-moore.com>, kbuild-all@...ts.01.org,
        Zeal Robot <zealci@....com.cn>, linux-kernel@...r.kernel.org,
        eparis@...hat.com, dai.shixin@....com.cn,
        Yang Yang <yang.yang29@....com.cn>, linux-audit@...hat.com,
        ink@...assic.park.msu.ru, huang.junhua@....com.cn,
        guo.xiaofeng@....com.cn, mattst88@...il.com
Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid

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@...hat.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@...il.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.

> > > > > 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@...hat.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