From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751713AbdCAEPt (ORCPT ); Tue, 28 Feb 2017 23:15:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49432 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751473AbdCAEPr (ORCPT ); Tue, 28 Feb 2017 23:15:47 -0500 From: Steve Grubb To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , Steven Rostedt , Ingo Molnar , Greg Kroah-Hartman , Al Viro , Eric Paris , Paul Moore Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs Date: Tue, 28 Feb 2017 23:15:38 -0500 Message-ID: <2137861.7RBAWtfTXJ@x2> Organization: Red Hat User-Agent: KMail/5.3.3 (Linux/4.9.12-100.fc24.x86_64; KDE/5.29.0; x86_64; ; ) In-Reply-To: <20170301033704.GU18258@madcap2.tricolour.ca> References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170301033704.GU18258@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.27]); Wed, 01 Mar 2017 04:15:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and > > > > DEBUGFS (and potentially other filesystems identified, via s_magic). XFS creates them too. Who knows what else. -Steve > > 2 - In __audit_inode_child, return after not finding the parent in that > > > > task context's audit names_list. > > > > 3 - In __audit_inode_child, mark the parent and its child as "hidden" > > > > when the parent isn't found in that task context's audit names_list. > > This will still result in an "items=" count that does not match the > > number of accompanying PATH records for that SYSCALL record, which > > may upset userspace tools but would still indicate suppressed > > records. > > > > 4 - In __audit_inode_child, when the parent isn't found, store the > > > > child's dentry in the child's (new or not) audit_names structure > > (properly refcounted with dget) and store the parent's dentry in its > > newly created audit_names structure (via dget_parent), then if the > > name isn't available at PATH record generation time, use that stored > > value (with dentry_path_raw and released with dput) > > > > Is there another more elegant solution that I've missed that catches > > things before they get anywhere near audit_inode_child (called from > > tracefs' notifiers)? > > > > I'll thread onto this message tested patches for all four solutions.