linux-kernel - Re: Hundreds of null PATH records for *init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170307034608.GT18258@madcap2.tricolour.ca>
Date:   Mon, 6 Mar 2017 22:46:08 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Jessica Yu <jeyu@...hat.com>
Cc:     Paul Moore <paul@...l-moore.com>, Steve Grubb <sgrubb@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs

On 2017-03-06 17:30, Jessica Yu wrote:
> +++ 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@...hat.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.

Yes, there is a lot going on in that function and by far the easiest way
to be able to load another module, but I'm being a bit paranoid in
suggesting that a rogue module may try and skip some steps listed there
and roll its own, hence the desire to not disable all PATH auxilliary
records for *_module SYSCALL records, but only the filesystem types that
don't pose a threat.

> Jessica

- RGB

--
Richard Guy Briggs <rgb@...hat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635