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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <624803f7.1c69fb81.972da.2dd0@mx.google.com>
Date:   Sat, 2 Apr 2022 08:06:12 +0000
From:   CGEL <cgel.zte@...il.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Steve Grubb <sgrubb@...hat.com>, linux-audit@...hat.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>,
        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 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?
> > > > 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ