Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932351AbdCINZe (ORCPT ); Thu, 9 Mar 2017 08:25:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48474 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753861AbdCINZc (ORCPT ); Thu, 9 Mar 2017 08:25:32 -0500 From: Steve Grubb To: Richard Guy Briggs Cc: Paul Moore , Jessica Yu , Greg Kroah-Hartman , LKML , Steven Rostedt , Linux-Audit Mailing List , Al Viro , Ingo Molnar 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> Organization: Red Hat In-Reply-To: <20170306214921.GR18258@madcap2.tricolour.ca> References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170306214921.GR18258@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 09 Mar 2017 13:25:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 625 Lines: 14 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