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;
MIME-Version: 1.0
References: <cover.1544477629.git.rgb@redhat.com> <43548fafdfa98ee64ecfd0d7a69a2f5cb2c31c50.1544477629.git.rgb@redhat.com>
 <CAHC9VhSaTvVgSWVWo42Ur2k6hVNJ1XBkLwrd-J4-SUuidwXUYg@mail.gmail.com> <20190117103255.1f640a42@ivy-bridge>
In-Reply-To: <20190117103255.1f640a42@ivy-bridge>
From:   Paul Moore <paul@paul-moore.com>
Date:   Thu, 17 Jan 2019 08:21:40 -0500
Message-ID: <CAHC9VhQvk+6AFjVU_ygyn8Q6FGwVy_JqXj7wWSNYYp5zSiBcuw@mail.gmail.com>
Subject: Re: [PATCH ghak59 V3 2/4] audit: add syscall information to
 CONFIG_CHANGE records
To:     Steve Grubb <sgrubb@redhat.com>,
        Richard Guy Briggs <rgb@redhat.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux-Audit Mailing List <linux-audit@redhat.com>,
        Eric Paris <eparis@redhat.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb <sgrubb@redhat.com> wrote:
> On Mon, 14 Jan 2019 17:58:58 -0500
> Paul Moore <paul@paul-moore.com> wrote:
>
> > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs <rgb@redhat.com>
> > 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

We've discussed this quite a bit already; connecting associated
records into a single event is something that should happen, needs to
happen, and will happen.  Conceptually it makes no sense to record the
syscall (and any other associated records) which triggers the audit
configuration change, and the configuration change record itself as
two distinct events - they are the same event.  We've also heard from
a prominent user that associating records in this way is desirable.

If the ausearch csv and text audit log transformations can't handle
this particular change, I would consider that a shortcoming of that
code.  We have multi-record events now, and this is only going to
increase in the future.

Richard, if you can't make the requested changes to this patch and
resubmit by ... let's say the middle of next week? that should be
enough time, yes? ... please let me know and I'll make the changes and
get this merged.

-- 
paul moore
www.paul-moore.com