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:   Sun, 9 Apr 2017 09:14:03 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Seth Forshee <seth.forshee@...onical.com>
Cc:     Eric Paris <eparis@...hat.com>, linux-audit@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: audit regressions in 4.11

On Sat, Apr 8, 2017 at 11:02 PM, Seth Forshee
<seth.forshee@...onical.com> wrote:
> I've observed audit regressions in 4.11-rc when not using a userspace
> audit daemon. The most obvious issue is that audit messages are not
> appearing in dmesg anymore. If a sufficient number of audit messages are
> generated the kernel will also start invoking the OOM killer.
>
> It looks like previously, when there's no auditd in userspace kauditd
> would call kauditd_hold_skb(), which prints the message using printk and
> either frees the skb or queues it (with a limit on the number of queued
> skb's by default).
>
> Since 5b52330bbfe6 "audit: fix auditd/kernel connection state tracking"
> when there's no auditd kauditd will instead use the retry queue, which
> has no limit. But it will not process the retry queue when there's no
> auditd, so messages pile up there indefinitely.

Hi Seth,

Thanks for the report.  Let me play with this and think on it for a
bit, but looking at the code again I think the issue is that we check
to see if auditd is connected at the top of the kauditd_thread() loop
and if it isn't we skip right to the main_queue label and bypass the
hold/retry queue processing which has the logic to ensure the retry
queue is managed correctly.  My initial thinking is that the fix is to
check and see if auditd is connected in kauditd_retry_skb(), if it
isn't we skip the retry queue and call kauditd_hold_skb(), if auditd
is connected we add the record to the retry queue (what we currently
do).

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ