From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754560AbdCGCFi (ORCPT ); Mon, 6 Mar 2017 21:05:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39532 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752742AbdCGCFS (ORCPT ); Mon, 6 Mar 2017 21:05:18 -0500 Date: Mon, 6 Mar 2017 16:49:21 -0500 From: Richard Guy Briggs To: Paul Moore Cc: Steve Grubb , 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 Message-ID: <20170306214921.GR18258@madcap2.tricolour.ca> References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170301033704.GU18258@madcap2.tricolour.ca> <2137861.7RBAWtfTXJ@x2> <20170303211454.GK3818@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 06 Mar 2017 21:49:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-03-03 19:22, Paul Moore wrote: > On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs wrote: > > On 2017-02-28 23:15, Steve Grubb wrote: > >> On Tuesday, February 28, 2017 10:37:04 PM EST 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 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. > >> > >> 0.5 - Notice that we are in *init_module & delete_module and inhibit > >> generation of any record type except SYSCALL and KERN_MODULE ? There are some > >> classification routines for -F perms=wrxa that might be used to create a new > >> class for loading/deleting modules that sets a flag that we use to suppress > >> some record types. > > > > Ok, I was partially able to do this. > > > > If I try and catch it in audit_log_start() which is the common point for > > all the record types to be able to limit to just SYSCALL and > > KERN_MODULE, there will already be a linked list of hundreds to > > thousands of audit_names and will still print a non-zero items count in > > the SYSCALL record. This also sounds like a potentially lazy way to > > deal with other record spam (like setuid BRPM_FCAPS). > > > > If I catch it in __audit_inode_child in the same place as I caught the > > filesystem type, it is effective for only the PATH record, which is all > > that is a problem at the moment. > > > > It touches nine arch-related files, which is a lot more disruptive than > > I was hoping. > > 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. > paul moore - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635