lkml.org 
[lkml]   [2020]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kernel panic: audit: backlog limit exceeded
On Mon, Mar 2, 2020 at 3:47 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Fri, Feb 28, 2020 at 2:09 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, Feb 28, 2020 at 5:03 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > > On 2020/02/28 9:14, Paul Moore wrote:
> > > > We could consider adding a fuzz-friendly build time config which would
> > > > disable the panic failsafe, but it probably isn't worth it at the
> > > > moment considering the syzbot's pid namespace limitations.
> > >
> > > I think adding a fuzz-friendly build time config does worth. For example,
> > > we have locations where printk() emits "BUG:" or "WARNING:" and fuzzer
> > > misunderstands that a crash occurred. PID namespace is irrelevant.
> > > I proposed one at
> > > https://lkml.kernel.org/r/20191216095955.9886-1-penguin-kernel@I-love.SAKURA.ne.jp .
> > > I appreciate your response.
> >
> > To be clear, I was talking specifically about the intentional panic in
> > audit_panic(). It is different from every other panic I've ever seen
> > (perhaps there are others?) in that it doesn't indicate a serious
> > error condition in the kernel, it indicates that audit records were
> > dropped. It seems extreme to most people, but some use cases require
> > that the system panic rather than lose audit records.
> >
> > My suggestion was that we could introduce a Kconfig build flag that
> > syzbot (and other fuzzers) could use to make the AUDIT_FAIL_PANIC case
> > in audit_panic() less panicky. However, as syzbot isn't currently
> > able to test the kernel's audit code due to it's pid namespace
> > restrictions, it doesn't make much sense to add this capability. If
> > syzbot removes that restriction, or when we get to the point that we
> > support multiple audit daemons, we can revisit this.
>
> Yes, we need some story for both panic and pid ns.
>
> We also use a separate net ns, but allow fuzzer to create some sockets
> in the init net ns to overcome similar limitations. This is done using
> a pseudo-syscall hack:
> https://github.com/google/syzkaller/blob/4a4e0509de520c7139ca2b5606712cbadc550db2/executor/common_linux.h#L1546-L1562
>
> But the pid ns is different and looks a bit harder as we need it
> during send of netlink messages.
>
> As a strawman proposal: the comment there says "for now":
>
> /* Only support auditd and auditctl in initial pid namespace
> * for now. */
> if (task_active_pid_ns(current) != &init_pid_ns)
> return -EPERM;
>
> What does that mean? Is it a kind of TODO? I mean if removing that
> limitation is useful for other reasons, then maybe we could kill 2
> birds with 1 stone.

Long story made short - the audit subsystem doesn't handle namespaces
or containers as well as it should. Work is ongoing to add the
necessary support, but it isn't there yet and I don't want us to just
start removing restrictions until we have the proper support in place
(this what I alluded to with my "... when we get to the point that we
support multiple audit daemons, we can revisit this").

--
paul moore
www.paul-moore.com

\
 
 \ /
  Last update: 2020-03-02 14:44    [W:0.079 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site