Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5093669imu; Tue, 15 Jan 2019 11:04:38 -0800 (PST) X-Google-Smtp-Source: ALg8bN7zJ2b1T5ZB/Bq3KU48Oj83rrybPW2z4M0Nb9WXHAFNMdk7+evMSBze5EYTyU5e4GOGQxD+ X-Received: by 2002:a63:8c6:: with SMTP id 189mr5160782pgi.322.1547579078352; Tue, 15 Jan 2019 11:04:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547579078; cv=none; d=google.com; s=arc-20160816; b=U93DxIVE3mC7t3pVhDQGIr+YtxKbyuVgNcXxl5isOvwmBtjclSjgUT08uPxcPf+FUR /4w8bbSt3ShTP03+MSIb8gnMS9F0fPxncPl/7+9Al6y0YDCWh9j8V5aOSj4LpPCYJkVx GQ17XLR/oqcR0M5F4GB9MrtikS5YkJJywpZ16BiNLmS4AwG4i/HfJnlMtISXjpG4HWsw TH2p5dNnvaT8RCYd7Kk/6wYm2iu0ZK9n+E2teS04uuTo52td4cH3defPrwHsnmGtq41b WvmYFcBQU4sPGG+Oof1Hqtv2DOTVLdQPBzIraY4kXY012DNVJiY7udDeAhwTIeMEgOMq 5Lhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=p6qV8Mv38Dh1Dz9YPLiG7PE+Az/mCtThXBurkKfMtqQ=; b=t15PSc/54c5L/ArGryHFd2gc5eRQybfGvsc7mF9+Wu1Qz/WW3GrxS1pYTud7rkM4vT GtXoN9t4NSm+EU7vfvMoLoycFS0iTCVC7LySJIhRASZZwmATCdEZPiNFs0E7skPC3jdw 6qTmZnqbaOfjO8dGyXPXk7hotaowRxIghN36PHOraC/hIUXD7mP05LZGAKPF57cdtNqW f2mtMWdHgmlFcRnPqHPuM7f8LbqAvm/sPAYKxzqSD6ogu22+kdyaT8j7dmG4zMh/JtaI BkkFHX9fpzKMmhCb6/YJNRhRWQv80xNFyoEgs+Ae4qYht7niowDgF86NxyXXma0YlUaM LZpw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 41si3859195plf.347.2019.01.15.11.04.18; Tue, 15 Jan 2019 11:04:38 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731444AbfAOQVS (ORCPT + 99 others); Tue, 15 Jan 2019 11:21:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48971 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730280AbfAOQVR (ORCPT ); Tue, 15 Jan 2019 11:21:17 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 317B2C057F93; Tue, 15 Jan 2019 16:21:17 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-10.phx2.redhat.com [10.3.112.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B62435D776; Tue, 15 Jan 2019 16:21:15 +0000 (UTC) Date: Tue, 15 Jan 2019 11:21:12 -0500 From: Richard Guy Briggs To: Paul Moore Cc: Linux-Audit Mailing List , LKML , Alexander Viro Subject: Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records Message-ID: <20190115162112.jq6m2j4wmyk4rq25@madcap2.tricolour.ca> References: <43548fafdfa98ee64ecfd0d7a69a2f5cb2c31c50.1544477629.git.rgb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 15 Jan 2019 16:21:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-14 17:58, Paul Moore wrote: > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs wrote: > > Tie syscall information to all CONFIG_CHANGE calls since they are all a > > result of user actions. > > > > Exclude user records from syscall context: > > Since the function audit_log_common_recv_msg() is shared by a number of > > AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_* record types, > > and since the AUDIT_CONFIG_CHANGE message type has been converted to a > > syscall accompanied record type, special-case the AUDIT_USER_* range of > > messages so they remain standalone records. > > > > See: https://github.com/linux-audit/audit-kernel/issues/59 > > See: https://github.com/linux-audit/audit-kernel/issues/50 > > Signed-off-by: Richard Guy Briggs > > --- > > kernel/audit.c | 27 +++++++++++++++++++-------- > > kernel/audit_fsnotify.c | 2 +- > > kernel/audit_tree.c | 2 +- > > kernel/audit_watch.c | 2 +- > > kernel/auditfilter.c | 2 +- > > 5 files changed, 23 insertions(+), 12 deletions(-) > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > index 0e8026423fbd..a321fea94cc6 100644 > > --- a/kernel/audit.c > > +++ b/kernel/audit.c > > @@ -1072,6 +1073,16 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type) > > audit_log_task_context(*ab); > > } > > > > +static inline void audit_log_user_recv_msg(struct audit_buffer **ab, u16 msg_type) > > +{ > > + audit_log_common_recv_msg(NULL, ab, msg_type); > > +} > > This makes sense because this is used by "user" records ... > > > +static inline void audit_log_config_change_alt(struct audit_buffer **ab) > > +{ > > + audit_log_common_recv_msg(audit_context(), ab, AUDIT_CONFIG_CHANGE); > > +} > > ... and I don't believe this makes sense because there is no real > logical grouping with the callers like there is for > audit_log_user_recv_msg(). I don't follow "logical grouping". They are all CONFIG_CHANGE record prefixes with the current context. Can you suggest an alternate name or another way of sharing audit_log_common_recv_msg() since the only differences between the two are a NULL context vs current task's context and the message type. I wasn't particularly happy with this name either. I'd really like to refactor this with all the rest of the CONFIG_CHANGE records, but there is too much of a format difference to make it work without reordering or deleting useless fields. I know you had suggested making two different functions, but I think they are more similar than different and merit the common factored code. > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635