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

On Wed, Mar 7, 2018 at 10:32 AM, Jiri Kosina <jikos@...nel.org> wrote:
> From: Jiri Kosina <jkosina@...e.cz>
>
> There is no point going through all the audit slow path syscall entry/exit
> in case the audit daemon is running, but hasn't populated the audit filter
> with any rules whatsoever.
>
> Only set TIF_AUDIT_SYSCALL in case the number of populated audit rules is
> non-zero.
>
> Originally-by: Andy Lutomirski <luto@...nel.org>
> Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> ---
>
> This is basically resurrection / rebase of patch Andi Lutomirski sent some
> time back in 2014 or so.
>
> Andi, is there any reason this hasn't been pursued further? I think we
> still want to get some of the slow path performance back.
>

Wow, this was a long time ago.  From memory and a bit of email diving,
there are two reasons.

1. The probably was partially solved (by Oleg, IIRC) by making
auditctl -a task,never cause newly spawned tasks to not suck.  Yes,
it's a very partial solution.  After considerable nagging, I got Fedora
to default to -a task,never.

2. This patch, as is, may be a bit problematic.  In particular, if one
task changes the audit rules while another task is in the middle of
the syscall, then it's too late to audit that syscall correctly.  This
could be seen as a bug or it could be seen as being just fine.

--Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ