From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755693AbdCGPji (ORCPT ); Tue, 7 Mar 2017 10:39:38 -0500 Received: from mail.kernel.org ([198.145.29.136]:42640 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752436AbdCGPj2 (ORCPT ); Tue, 7 Mar 2017 10:39:28 -0500 Date: Tue, 7 Mar 2017 10:37:27 -0500 From: Steven Rostedt To: Paul Moore Cc: Richard Guy Briggs , Linux-Audit Mailing List , LKML , Greg Kroah-Hartman , Ingo Molnar , Al Viro Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs Message-ID: <20170307103727.78661e8a@gandalf.local.home> In-Reply-To: References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170301033704.GU18258@madcap2.tricolour.ca> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 3 Mar 2017 19:19:47 -0500 Paul Moore wrote: > On Tue, Feb 28, 2017 at 10:37 PM, Richard Guy Briggs wrote: > > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > > alt patches. > > > > On 2017-02-28 22:15, Richard Guy Briggs wrote: > >> The background to this is: > >> https://github.com/linux-audit/audit-kernel/issues/8 > >> > >> In short, audit SYSCALL records for *init_module were occasionally > >> accompanied by hundreds to thousands of null PATH records. > >> > >> I chatted with Al Viro and Eric Paris about this Friday afternoon and > >> they seemed to vaguely recall this issue and didn't have any solid > >> recommendations as to what was the right thing to do (other than the > >> same suggestion from both that I won't print here). > >> > >> It was reproducible on a number of vintages of distributions with > >> default kernels, but triggering on very few of the many modules loaded > >> at boot time. It was reproduced with fs-nfs4 and nfsv4 modules on > >> tracefs, but there are reports of it also happening with debugfs. It > >> was triggering only in __audit_inode_child with a parent that was not > >> found in the task context's audit names_list. > > I'm no expert on the tracing system, but my understanding is that it > used to use debugfs but now prefers tracefs so perhaps depending on > the vintage of the kernel/userspace you will see it on either debugfs > or tracefs. I'm also guessing that module load order may have an > effect, maybe not. Note, when you mount debugfs, it automounts tracefs in debugfs/tracing. Userspace can also mount tracefs without debugfs. But tracing does not use debugfs anymore, even though it appears in the debugfs directory. > > >> I have four potential solutions listed in my order of preference and I'd > >> like to get some feedback about which one would be the most acceptable. > > >From an audit perspective, I'm generally not a fan of throwing away > information, especially since solution #4 seems to provide some basic > PATH information. Although I guess the issue is do we care about > tracefs/debugfs PATH records? I don't have enough context here to really understand what the issue is. Is there a problem when modules have trace events and when they are loaded, these trace events create files and directories in the tracefs file system? -- Steve