Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp457837pxk; Wed, 23 Sep 2020 07:31:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxh94lYAVLrifXnPZRHpItXR4ZYtKtx3EoA7/Qj87qiunxqiLwXa6T5RxtnZSyAY06I/taW X-Received: by 2002:a17:906:4c58:: with SMTP id d24mr10908337ejw.108.1600871498701; Wed, 23 Sep 2020 07:31:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600871498; cv=none; d=google.com; s=arc-20160816; b=N6yxDn9K2WR/2bg9lvwPV6NbOeH9dV6nPtqA2pe6xWk6w63uXkiipS4iMbtRAeJX7v a4QHGGYuSxGl0yMLbjIj7GX5XqxC7qzxC0mb0p4s3SKT0erFh1YeKTZOFeq+1pTmH6S9 UzI2hWHaXsREtK5FFaZavt66A8vK8muq0ZTp6/NYyKd/5YbeF9h0qcvxuOV3j2e+2wXm 1Qe6LtEtvoQefibFShr5vMqSkdn+HA29e6Yc+Aa3xOwz3BThKQY5Iv9NYi019ht+IdkI 8l1ZltCNFuDg/0XzZMXQ8T6KykJx4+mN8mgYPyWa+/+mWmc7KCpfKgJGrAOSI0SmTuJp ezHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=BvWaZAOmCSJi5EjRj+9rGgqiUccGff1Wvin8E59j7sU=; b=tHbfxLJ5g9vrCYuuUb9rN1oQoEsDwJpPn2YegL96uM4dITezsUY/l/uiiYsEEFJGsm 60D2hWEcDz/nyerHZ53ZJIHE6IvDwid7TnjhekkqzvTVAcbOcxLpj28hW8Ybtib3y1TQ h9os8V+F2Sq8h54ZWxi8UYkQD5Z1tpXWzTja96K/nG0Wdm+SuqLVeiiFzPRa8JrnakZg mak7D3zsWtGWiRWmnD1gRLSKhxL9BQV1OnJHHG++TU+MCDeoxw6vfET4HdKCc+CCHBRD VbJZp3gq33GbjR/gUo5YarD5wNdyEopnYzYrcZlKFwKPfwR5Xcyf8PplJl/NXJ0hJPxP m/pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=xcSixdr2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e23si13677512edc.428.2020.09.23.07.31.12; Wed, 23 Sep 2020 07:31:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=xcSixdr2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726672AbgIWO34 (ORCPT + 99 others); Wed, 23 Sep 2020 10:29:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726156AbgIWO3y (ORCPT ); Wed, 23 Sep 2020 10:29:54 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDB05C0613D1 for ; Wed, 23 Sep 2020 07:29:53 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id gr14so28117261ejb.1 for ; Wed, 23 Sep 2020 07:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BvWaZAOmCSJi5EjRj+9rGgqiUccGff1Wvin8E59j7sU=; b=xcSixdr2ga+Acx/jNRq3SciNJm/k6+0O76py84OD8DfGApvaqZaQlYynrd/DMYINvD w6AM3RwHPUJxID/5ETNaJsTfv75T1xOGBSSw/SO0W3/mJtxFd2IcLb2W6h7JymFMiEtg GM+PJKEGwJAGFkTM5rHfYOWNVWgyF1p9kEjLe8wA6FhYBGdeHvR31/W0Hj5LvnJUP5ft M6t4IedE1LKk6fTaDwqLmqK9cv6Cz9HQSdwUgk3sCPM94ZJ96Q172m6xA+lM3smf+TzW 4IKqJQeqjAlLtIsemGF910S2HOlzV0lY6Ef9609bDIxRkKoOg8Xhv9OQSlis+D/3l7yN oz7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BvWaZAOmCSJi5EjRj+9rGgqiUccGff1Wvin8E59j7sU=; b=Yjw/FR9uGXNDZXQHOKNoTKUNcpXlLQH3/sA7vhBMvbOwdlzjmnHNYnNrxLbadtAlfA AZ7kq6cg9mDxeLZUh7B9pVGrlbUvFiCtvSSVWNyWK4/+AAqqGwF39jJPSzveXFcL9Ct9 q+o9oUNK3nX9nNnegs00ui7zQEu887TeqB2ljQ/JcALBUgEHWung3ucACE67IJP7c7hE N9vj/rwoJ5+UK0RABsYGUwQ//QVBOX7xhez+0Y6cT5H+ZI1zMzNqleAW0BjLEYZ9gbvp nydDGtOkBZxGTvyv+OY+XhwwW+iJpnSvhtMT5vbbzDbMzsP+IOYw693WGtEsGVazkVMC pJ0A== X-Gm-Message-State: AOAM531p2M9LMUycMQZbSKWkg92EzNHAYhY7pk0Z0hyTR3k8087v+vg2 Ugc47cId6L+Kq7PWjpvrJqhBpyQvOtyNiJeztSP2 X-Received: by 2002:a17:906:2301:: with SMTP id l1mr10188672eja.488.1600871392179; Wed, 23 Sep 2020 07:29:52 -0700 (PDT) MIME-Version: 1.0 References: <7081a5b9c7d2e8085c49cec2fa72fcbb0b25e0d7.1600778472.git.rgb@redhat.com> In-Reply-To: <7081a5b9c7d2e8085c49cec2fa72fcbb0b25e0d7.1600778472.git.rgb@redhat.com> From: Paul Moore Date: Wed, 23 Sep 2020 10:29:41 -0400 Message-ID: Subject: Re: [PATCH ghak120 V5] audit: trigger accompanying records when no rules present To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , Linux Security Module list , Eric Paris Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2020 at 8:45 AM Richard Guy Briggs wrote: > > When there are no audit rules registered, mandatory records (config, > etc.) are missing their accompanying records (syscall, proctitle, etc.). > > This is due to audit context dummy set on syscall entry based on absence > of rules that signals that no other records are to be printed. Clear the dummy > bit if any record is generated, open coding this in audit_log_start(). > > The proctitle context and dummy checks are pointless since the > proctitle record will not be printed if no syscall records are printed. > > The fds array is reset to -1 after the first syscall to indicate it > isn't valid any more, but was never set to -1 when the context was > allocated to indicate it wasn't yet valid. > > Check ctx->pwd in audit_log_name(). > > The audit_inode* functions can be called without going through > getname_flags() or getname_kernel() that sets audit_names and cwd, so > set the cwd in audit_alloc_name() if it has not already been done so due to > audit_names being valid and purge all other audit_getcwd() calls. > > Revert the LSM dump_common_audit_data() LSM_AUDIT_DATA_* cases from the > ghak96 patch since they are no longer necessary due to cwd coverage in > audit_alloc_name(). > > Thanks to bauen1 for reporting LSM situations in > which context->cwd is not valid, inadvertantly fixed by the ghak96 patch. > > Please see upstream github issue > https://github.com/linux-audit/audit-kernel/issues/120 > This is also related to upstream github issue > https://github.com/linux-audit/audit-kernel/issues/96 > > Signed-off-by: Richard Guy Briggs > --- > Chagelog: > v5: > - open code audit_clear_dummy() in audit_log_start() > - fix check for ctx->pwd in audit_log_name() > - open code _audit_getcwd() contents in audit_alloc_name() > - ditch all *audit_getcwd() calls > > v4: > - resubmit after revert > > v3: > - initialize fds[0] to -1 > - init cwd for ghak96 LSM_AUDIT_DATA_NET:AF_UNIX case > - init cwd for audit_inode{,_child} > > v2: > - unconditionally clear dummy > - create audit_clear_dummy accessor function > - remove proctitle context and dummy checks > > include/linux/audit.h | 8 -------- > kernel/audit.c | 3 +++ > kernel/auditsc.c | 27 +++++++-------------------- > security/lsm_audit.c | 5 ----- > 4 files changed, 10 insertions(+), 33 deletions(-) I've gone over this revision a couple of times now and it looks okay, but past experience is whispering in my ear that perhaps this is better to wait on this for the next cycle so it gets a full set of -rcX releases. Thoughts? -- paul moore www.paul-moore.com