Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932747AbdCGRk6 (ORCPT ); Tue, 7 Mar 2017 12:40:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35018 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbdCGRkt (ORCPT ); Tue, 7 Mar 2017 12:40:49 -0500 Date: Tue, 7 Mar 2017 12:39:55 -0500 From: Richard Guy Briggs To: Steven Rostedt Cc: Paul Moore , Linux-Audit Mailing List , LKML , Greg Kroah-Hartman , Ingo Molnar , Al Viro Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs Message-ID: <20170307173955.GC10258@madcap2.tricolour.ca> References: <20170301031549.GT18258@madcap2.tricolour.ca> <20170301033704.GU18258@madcap2.tricolour.ca> <20170307033954.GS18258@madcap2.tricolour.ca> <20170307104139.38f5cd38@gandalf.local.home> <20170307160027.GB10258@madcap2.tricolour.ca> <20170307112056.4e27424a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170307112056.4e27424a@gandalf.local.home> 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.29]); Tue, 07 Mar 2017 17:40:03 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2270 Lines: 56 On 2017-03-07 11:20, Steven Rostedt wrote: > On Tue, 7 Mar 2017 11:00:27 -0500 > Richard Guy Briggs wrote: > > > On 2017-03-07 10:41, Steven Rostedt wrote: > > > On Mon, 6 Mar 2017 22:39:54 -0500 > > > Richard Guy Briggs wrote: > > > > > > > >From the output I've seen, it doesn't look particularly useful, but it > > > > was useful to finally see the source of those huge numbers of PATH > > > > records. Here's an fpaste: > > > > https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/ > > > > > > Those are the files for the module's trace events that are created. > > > > > > I'm still confused about what the issue is. > > > > The issue is the audit subsystem being overwhelmed by potentially > > useless information. > > > > The initial report was "there's a bunch of null PATH records, please > > make them go away", which was anywhere from 500 to 6000 records. > > I don't know the audit system and exactly what it is looking for. How > does it deal with other virtual filesystems like procfs? Why is tracefs > different? The audit subsystem is looking, via sysadmin-crafted rules to notice situations of interest, for details that could affect the integrity of the system This situation is specifically for syscall auditing. Various syscalls have expected numbers of accompanying PATH records, for example open(2) would have directory and file PATH records, while rename(2) would have 2 directory and 2 file PATH records. An open call on a file in /proc could trigger a rule that was formulated to catch that type of activity that lists its directory and its file PATH records, which would be fine. We normally don't expect the init_module syscall to have any PATH records associated with it, so when a few of them had hundreds or more this was surprising. If there is a way that debugfs or tracefs could be abused during an init_module call (or any other syscall for that matter), we want to be aware of it. This is why simply ignoring those PATH records is making two of us nervous. > -- Steve - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635