Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1813287imu; Thu, 17 Jan 2019 03:45:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN7G9zDiUNEvn40mhXuWq4iTyUjNM/OlwhD+91wO3LCI+QJco8XdqTpSaS4aRAI8JTWO3i4L X-Received: by 2002:a62:5003:: with SMTP id e3mr15012435pfb.23.1547725548701; Thu, 17 Jan 2019 03:45:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547725548; cv=none; d=google.com; s=arc-20160816; b=FkkhqUR0ToNBsWGlhseKJ+ham2taXphlvPDVNycmMSlTarl28GOzKY/491LYWRwSEn eQnSm56twnIr7aGqAhMVKjxCZgaT5m0+7k+dLgocOND7usY3zaPcy56nQ/bvFuYWD0bq KRC83de4bAzayzbk92CpW+f4GhPq0mcajPDbtBF0XTzC924MIrLz1xkWPXRfkPLDZ3HO jQbcP2XNs3E+co+emoVcxbmBYh7i9ogb/jey/a13KxwlkttYGTjlr9I0WuPgG7P8YvBZ 3syOc2SqHN0B2Zbj2vxXlFBCZ0PCuYj86YtKZjRQZDD63vEgoFbo0W5VwzhtjSsF6PTo 5xWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=qjXd1pVIGAe70fM1pBmq+LG0yHPa9uFnrDvj5+aNjDA=; b=oWtyOqdi1CDGUKk4HP83cjZcrdvWPhurXwvFEUR68cvSQnSTVFWp+c0pApG7xbnO6h qwLZLZxBQxVJe7T0bvNd00zUan5wytjNLhdHvKOXU0uDzRQS0V1HONDpB+aEyZhoCEAJ xGNp1mSQxZUcweP2bFG7RNt/Sz/on2IG58SIOos4tAhkgNvdx0SEyvVwc14cyidr8znY 6O4i0iL3gKalQQXXtS2eXKqol7bVLNq/T4U8F4WHo1X1Rk4WRZvL8sem9X4OgsJcG93x LpgT5/t6ACKbhkKDHNG+0LeXNdNcw9Y/JcUBZpLoMWDcSliaISrC1CxuQXAvoqQ48Fsc OzLQ== 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 ce11si1497022plb.420.2019.01.17.03.45.33; Thu, 17 Jan 2019 03:45:48 -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 S1727620AbfAQJdG (ORCPT + 99 others); Thu, 17 Jan 2019 04:33:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45344 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726727AbfAQJdF (ORCPT ); Thu, 17 Jan 2019 04:33:05 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 890DCCD263; Thu, 17 Jan 2019 09:33:05 +0000 (UTC) Received: from ivy-bridge (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B64560BE8; Thu, 17 Jan 2019 09:32:56 +0000 (UTC) Date: Thu, 17 Jan 2019 10:32:55 +0100 From: Steve Grubb To: Paul Moore Cc: Richard Guy Briggs , LKML , Linux-Audit Mailing List , Eric Paris , Alexander Viro Subject: Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records Message-ID: <20190117103255.1f640a42@ivy-bridge> In-Reply-To: References: <43548fafdfa98ee64ecfd0d7a69a2f5cb2c31c50.1544477629.git.rgb@redhat.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 17 Jan 2019 09:33:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2019 17:58:58 -0500 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. Please don't tie syscall information to this. The syscall will be sendto. We don't need that information, its implicit. Also, doing this will possibly wreck things in libauparse. Please test the events with ausearch --format csv and --format text. IFF the event looks better or the same should we do this. If stuff disappears, the patch is breaking things -Steve > > 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(). >