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:   Fri, 01 Nov 2019 10:16:56 -0400
From:   Steve Grubb <sgrubb@...hat.com>
To:     linux-audit@...hat.com
Cc:     Chris Mason <clm@...com>, Paul Moore <paul@...l-moore.com>,
        Dave Jones <davej@...emonkey.org.uk>,
        Kyle McMartin <jkkm@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] audit: set context->dummy even when audit is off

On Friday, November 1, 2019 9:24:17 AM EDT Chris Mason wrote:
> On 31 Oct 2019, at 19:27, Paul Moore wrote:
> > On Thu, Oct 31, 2019 at 12:40 PM Chris Mason <clm@...com> wrote:
> > [ ... ]
> > Hi Chris,
> > 
> > This is a rather hasty email as I'm at a conference right now, but I
> > wanted to convey that I'm not opposed to making sure that the NTP
> > records obey the audit configuration (that was the original intent
> > after all), I think it is just that we are all a little confused as to
> > why you are seeing the NTP records *and*only* the NTP records.
> 
> This part is harder to nail down because there's a window during boot
> where journald has enabled audit but chef hasn't yet run in and turned
> it off, so we get a lot of logs early and then mostly ntp after that.

This is the root of the problem. Journald should never turn on audit since it 
has no idea if auditd even has rules to load. What if the end user does not 
want auditing? By blindly enabling audit without knowing if its wanted, it 
causes a system performance hit even with no rules loaded. It would be best 
if journald leaves audit alone. If it wants to listen on the multicast 
socket, so be it. It should just listen and not try to alter the system.

Back to ntp, it sounds like the ntp record needs to check for audit_enabled 
rather than the dummy context.

-Steve



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ