From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Grubb <sgrubb@redhat.com>
Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs
Date: Thu, 09 Mar 2017 08:25:30 -0500
Message-ID: <1506758.nmGZ90BLZd@x2>
References: <20170301031549.GT18258@madcap2.tricolour.ca> <CAHC9VhQSvMuvbMGroz6MBo=BFxERr4QhQkmW1fpTXJvcaiqsaw@mail.gmail.com> <20170306214921.GR18258@madcap2.tricolour.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20170306214921.GR18258@madcap2.tricolour.ca>
Sender: linux-kernel-owner@vger.kernel.org
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Jessica Yu <jeyu@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Linux-Audit Mailing List <linux-audit@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@redhat.com>
List-Id: linux-audit@redhat.com

On Monday, March 6, 2017 4:49:21 PM EST Richard Guy Briggs wrote:
> > Blocking PATH record on creation based on syscall *really* seems like
> > a bad/dangerous idea.  If we want to block all these tracefs/debugfs
> > records, let's just block the fs.  Although as of right now I'm not a
> > fan of blocking anything.
> 
> I agree.  What makes me leery of this approach is if a kernel module in
> turn accesses directly other files, or bypasses the load_module call to
> load another module from a file and avoids logging.

In this case, we want a second event with that module name. We do not want any 
PATH records.

-Steve