linux-kernel - Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

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:   Sat, 10 Mar 2018 11:15:35 +0100
From:   Steve Grubb <sgrubb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Jiri Kosina <jikos@...nel.org>, Andy Lutomirski <luto@...nel.org>,
        linux-audit@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Oleg Nesterov <oleg@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] audit: set  TIF_AUDIT_SYSCALL only if audit filter has
 been populated

On Wed, 7 Mar 2018 18:43:42 -0500
Paul Moore <paul@...l-moore.com> wrote:
> ... and I just realized that linux-audit isn't on the To/CC line,
> adding them now.
> 
> Link to the patch is below.
> 
> * https://marc.info/?t=152041887600003&r=1&w=2

Yes...I wished I was in on the beginning of this discussion. Here's the
problem. We need all tasks auditable unless specifically dismissed as
uninteresting. This would be a task,never rule.

The way we look at it, is if it boots with audit=1, then we know auditd
is expected to run at some point. So, we need all tasks to stay
auditable. If they weren't and auditd enabled auditing, then we'd need
to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
process in the system. It was decided that this is too ugly.

So, we need them all to be auditable if there is any intent to audit.
It doesn't matter if there are rules loaded or not. All processes have
to stay within reach.

What might be acceptable is to add one more state to audit boot variable
to indicate that auditing is never expected. We currently have:
disabled - which means we'll decide later, enabled, and immutable (no
changes allowed). Then have calls to audit_enable or loading rules
fail on that flag state so that user space can log that there is a
conflict (boot vs daemon) that has to be resolved. As long as we can
fail in a discoverable way, I think it would be OK to do something like
this. Also, I don't think we want that to be the default state at the
moment because the current default is keep all processes auditable.

-Steve