Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2038705imu; Thu, 17 Jan 2019 07:24:29 -0800 (PST) X-Google-Smtp-Source: ALg8bN4MyYed56Qm6UFSPjfidlZBWr1On9RbI4llQDds/xIlQm3rBWTFTbDLLgpcEzwTMDcErg9i X-Received: by 2002:a62:3603:: with SMTP id d3mr15841116pfa.146.1547738669645; Thu, 17 Jan 2019 07:24:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547738669; cv=none; d=google.com; s=arc-20160816; b=kQ2QDy8AN8qY19fXEazYzI94Kw8AL/TVLHsp48W2M/dvqr1KH9IXZE5LNFCs3kia68 Lj8zGu8jADIGarbU1U3smyZutsvWrFzxiYKnBL2G4Af5XkL2LOHwqKCweJicSGFI+gFN T5ceWaJMKEHhhRYKms9oj90FfUkSE33aKHKZJHqrZwc/7muJUzwOrT6fx+0BJYuPUXaz tOdytbY3dFyqHQexwzoMYWzrHuoYW6ZHgDWYU1c5TWTiKaoEM9neTddEgd14+Pn6j4t8 EZ1LNBNIzIP8mci+sdTjb3zlGUDz+7Ubwhvl1HtIRc0ksjViILnVq7+YBu+tememL0iy PdvQ== 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=pBIN7gFh9VIZzes5eJLsgh9UQb8Dy/PtHpCsCp9KWms=; b=tSRXoP87OcC0gIq2qXaQOF0xiUL5Xd2dYZA50LPD96rL07E57j8hpmA5AJP8zYC7U0 IwllnzHNKwkRvDlozhhunjIgqtn6oWI5t5ITrXfobaYf/ETznexNeu4aNOqFiBiQu7Zy xRhZMvMBI9Kg1x9Kq9zPe65HMzVsoKwwS6H+N9ID1yZINfwZU73oTDNKbWoDcMbexhr9 XS6W3R6y20PN9MfykP0e6jmB3DYvQV757J76cqyRkG6e9/j+uT/zmLpFd3//Gp9GrBaQ paUjhxHzW9Q+qH2Nor4Qd9PHAgINTahHYkOSLFD6QWNSE9My2r7oclrsMiC4719r0uvv ypUA== 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 i198si1997006pfe.289.2019.01.17.07.24.14; Thu, 17 Jan 2019 07:24:29 -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 S1727828AbfAQPFa (ORCPT + 99 others); Thu, 17 Jan 2019 10:05:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60866 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727165AbfAQPFa (ORCPT ); Thu, 17 Jan 2019 10:05:30 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 61D798667A; Thu, 17 Jan 2019 15:05:29 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-19.phx2.redhat.com [10.3.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 483D92C16D; Thu, 17 Jan 2019 15:05:21 +0000 (UTC) Date: Thu, 17 Jan 2019 10:05:18 -0500 From: Richard Guy Briggs To: Steve Grubb Cc: Paul Moore , Linux-Audit Mailing List , LKML , Alexander Viro Subject: Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records Message-ID: <20190117150518.i2yh5te25zytwcuf@madcap2.tricolour.ca> References: <43548fafdfa98ee64ecfd0d7a69a2f5cb2c31c50.1544477629.git.rgb@redhat.com> <20190117103255.1f640a42@ivy-bridge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190117103255.1f640a42@ivy-bridge> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 17 Jan 2019 15:05:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-17 10:32, Steve Grubb wrote: > 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, I hope you aren't talking about the AUDIT_*USER* records, because this patch intentionally leaves them unassociated with the syscall record. The config change records are related. > -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(). - 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