Received: by 10.223.185.116 with SMTP id b49csp5646586wrg; Wed, 7 Mar 2018 15:45:17 -0800 (PST) X-Google-Smtp-Source: AG47ELtW2eyUq5SE9nEvxntEu7Ja1p4L1Bu2PxU5NbVcoEIR8g0DUYyaZMSkOE9NjGgYSeukWNPx X-Received: by 2002:a17:902:983:: with SMTP id 3-v6mr7633390pln.278.1520466317304; Wed, 07 Mar 2018 15:45:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520466317; cv=none; d=google.com; s=arc-20160816; b=r2pjpKu2ulFAKlmNxw+PdgoWIpNuZXiQyrfUnK5pmFl+WzASpy4+3ka8qG6w74wXIY rWlAM00gwBUXSpN+ute/d43GsbU86TLrC6A3k3PkdJJAt0kLMFzMLFqrt+GXdSKFsm1o deX08nuoZOqZNiD9xEN612XeaQfNyE1d49G6L+ZoCDOEzyNAXZk7/qNE+R7ZeAH19uC8 TEOVAjF4nNoQP1oHDfEWjjPLAzB9iFZ4gVKO1JIwaZC3rQJ5MX3XmrbVKxdn7BZxKOO/ iebmWb7aPNij74703AdX6oq7Ygiy9GQ8ALZ7Xtglr2B05YKhblOfZWNGO+kAFh8u836p v/fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=S3z7yK+GnG6L65kdl0wboOtcj5RAP3U1wZUmhE5IgiQ=; b=SIepYLWPXfJ998LsueX1rVJ9G2FAREnQ6IoY0hWtrv7DzOgDbTy1GcjsHZKhbqfEog cu7GC7u2lYODiTH4JEPsCkKEEMzJFD8tpbG9W8QgeVVZhnSOYazceSYC9tsn/hTVo71V HAm+oou6Y48YmxGJvcU2R4iXjqEscUOCSmsfZhdUxJbIptaNXOghHkCnYA67fLItVqoI 3SFmDlbAGXTkIGy9jmhYQpmbArukAz7wvgmQtYdmJmz4QGGH4vK2h9qF6nn0anCDSRO/ U4FwfJlJLrTnVwzxSnhwk4i3aW2hW63AxZlMLNExwtv1ahC+PLNa5Y7GoWSf89fAcu+Y azQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=SR+cpJDm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k23-v6si13812258pls.42.2018.03.07.15.45.02; Wed, 07 Mar 2018 15:45:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=SR+cpJDm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755064AbeCGXnq (ORCPT + 99 others); Wed, 7 Mar 2018 18:43:46 -0500 Received: from mail-lf0-f50.google.com ([209.85.215.50]:46392 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754998AbeCGXnp (ORCPT ); Wed, 7 Mar 2018 18:43:45 -0500 Received: by mail-lf0-f50.google.com with SMTP id r80-v6so5754664lfe.13 for ; Wed, 07 Mar 2018 15:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S3z7yK+GnG6L65kdl0wboOtcj5RAP3U1wZUmhE5IgiQ=; b=SR+cpJDmi73VpfI2k1JsblXV8/vpV7MGewla7QjLj9HREm2A84eP+kmGLKyjGHSFNF sJ1MHfVrf5U0tf2YYaHOSBRL+5QtnlfpYolRAB1tpOM38Q5KJBGmHKIoHAenLzbpl07+ KCqwRIctLACod+fk6tiWQgHJeL8wkf3MEVcOK0dZOsSMl2jJJrcLkcRTIz/Dgj59EGC/ 4ruactSYV9aZyog4FvhCfqiVG3AXEcvp+MwMoOEnpz5OCENROYfAJGhpTXY1AdqSAW0K WEEmftYkk7HKaxjpwDhW0tpbF/vs+krdcO8gE9SZmjEbyWXnug93WZglc5EFhhSlEg/O BcLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S3z7yK+GnG6L65kdl0wboOtcj5RAP3U1wZUmhE5IgiQ=; b=TunMWx4TXBPbYR8/w2AiwIDVMP3Ea+MjWTQ3Y56drB8fbMEpgFNXRVPWNqHwAu1o9I KZQfdgUDFOqVouZkoozl07Ho5G1i3QRphtk5xvM0PkBdzuzUEEOReGKw2Lx6Iu7ikkFI EWKw4L5o1lkefnw3pmOwyhxELJ8Xd4FyCGpusTPvhvntRdzvnrFxUDjC2lwwILDYvd6g 38Ouzso12yb+TcDMHWzPHxfI8vFTMNbXKXCI+cH2CIfmxmklyolQGCNTx8Q1ykl87VFQ 9lOqdcJOTLuTLhmmoEEKhtJQ2eIdTuN9jj3Oe609+G4D907e0afbyAfMRf57WDyZ2DAy 4dpA== X-Gm-Message-State: AElRT7FqzZtfd0A9wiKfOjctZbxmZ7nR+P8MpzPsqQ793eI86mUD4nbV 9Ris1T/O68FxZu+2Ccfi3kbsTgxTjAn5PCKPi1hm X-Received: by 10.46.124.11 with SMTP id x11mr353394ljc.72.1520466223819; Wed, 07 Mar 2018 15:43:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.216.167 with HTTP; Wed, 7 Mar 2018 15:43:42 -0800 (PST) X-Originating-IP: [108.20.156.165] In-Reply-To: References: From: Paul Moore Date: Wed, 7 Mar 2018 18:43:42 -0500 Message-ID: Subject: Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated To: Jiri Kosina , Andy Lutomirski Cc: Oleg Nesterov , Andrew Morton , Michal Hocko , LKML , linux-audit@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 7, 2018 at 6:41 PM, Paul Moore wrote: > On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote: >> On Wed, 7 Mar 2018, Andy Lutomirski wrote: >>> Wow, this was a long time ago. >> >> Oh yeah; but it now resurfaced on our side, as we are of course receiving >> a lot of requests with respect to making syscall performance great again >> :) > > Ooof. I'm not sure I can handle making more things "great again" ;) > >>> 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. >> >> Hm, right; that's a bit inconvenient, because it takes each and every >> vendor having to realize this option, and put it in. Making kernel do the >> right thing automatically sounds like a better option to me. > > This predates audit falling into my lap, but speaking generally I > think it would be good if the kernel did The Right Thing, so long as > it isn't too painful. > >>> 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. >> >> I don't think this should be a problem, given the fact that the whole >> timing/ordering is not predictable anyway due to scheduling. >> >> Paul, what do you think? > > I'm not overly concerned about the race condition between configuring > the audit filters and syscalls that are currently in-flight; after all > we have that now and "fixing" it would be pretty much impractical > (impossible maybe?). Most serious audit users configure it during > boot and let it run, frequent runtime changes are not common as far as > I can tell. > > I just looked quickly at the patch and decided it isn't something I'm > going to be able to carefully review in the time I've got left today, > so it's going to have to wait until tomorrow and Friday ... however, > speaking on general principle I don't have an objection to the ideas > put forth here. > > Andy, if you've got any Reviewed-by/Tested-by/NACK/etc. you want to > add, that would be good to have. ... 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 -- paul moore www.paul-moore.com