Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752271AbdCDAXT (ORCPT ); Fri, 3 Mar 2017 19:23:19 -0500 Received: from mail-ua0-f179.google.com ([209.85.217.179]:33512 "EHLO mail-ua0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752089AbdCDAXS (ORCPT ); Fri, 3 Mar 2017 19:23:18 -0500 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: <20170303211454.GK3818@madcap2.tricolour.ca> References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170301033704.GU18258@madcap2.tricolour.ca> <2137861.7RBAWtfTXJ@x2> <20170303211454.GK3818@madcap2.tricolour.ca> From: Paul Moore Date: Fri, 3 Mar 2017 19:22:52 -0500 Message-ID: Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs To: Richard Guy Briggs Cc: Steve Grubb , Jessica Yu , Greg Kroah-Hartman , LKML , Steven Rostedt , Linux-Audit Mailing List , Al Viro , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2818 Lines: 58 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. -- paul moore www.paul-moore.com