Date: Mon, 6 Mar 2017 17:30:02 -0500
From: Jessica Yu <jeyu@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Steve Grubb <sgrubb@redhat.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linux-Audit Mailing List <linux-audit@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@redhat.com>
Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs
Message-ID: <20170306223002.GA23805@packer-debian-8-amd64.digitalocean.com>
References: <20170301031549.GT18258@madcap2.tricolour.ca>
 <20170301033704.GU18258@madcap2.tricolour.ca>
 <2137861.7RBAWtfTXJ@x2>
 <20170303211454.GK3818@madcap2.tricolour.ca>
 <CAHC9VhQSvMuvbMGroz6MBo=BFxERr4QhQkmW1fpTXJvcaiqsaw@mail.gmail.com>
 <20170306214921.GR18258@madcap2.tricolour.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20170306214921.GR18258@madcap2.tricolour.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3709
Lines: 70

+++ Richard Guy Briggs [06/03/17 16:49 -0500]:
>On 2017-03-03 19:22, Paul Moore wrote:
>> On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb@redhat.com> 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.

AFAIK load_module is *the* entry point for module loading, it is where
all the setup occurs in order for a module to be properly set up and
registered in our internal data structures (e.g the global modules
list). If a module wants another module loaded, it can request for it
to be loaded via request_module(), which punts the request to modprobe
in userspace to load the module in question, but I'm not sure if
that's at all related to this null PATH record issue.

Jessica