Message-ID: <20170307220023.GF10258@madcap2.tricolour.ca>
Date:   Tue, 7 Mar 2017 17:00:23 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Paul Moore <paul@...l-moore.com>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs

On 2017-03-07 14:09, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 13:34:47 -0500
> Richard Guy Briggs <rgb@...hat.com> wrote:
> 
> > On 2017-03-07 13:04, Steven Rostedt wrote:
> > > On Tue, 7 Mar 2017 12:39:55 -0500
> > > Richard Guy Briggs <rgb@...hat.com> wrote:
> > >   
> > > > 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.  
> > > 
> > > Hmm, how does the syscall get a path associated to it? Just by its
> > > creation? That is, by calling init_module() which would load a module,
> > > would indeed create a path. Some modules do create their own debugfs
> > > files, which would explain why debugfs is shown too.  
> > 
> > My understanding is that a module binary blob is already acquired from
> > some source and then handed to the init_module (or finit_module) syscall
> > to add to the running kernel.  Some add functionality in /proc or /sys,
> > but these would not be exercised until they are called by name from
> > another syscall (such as open).
> > 
> > Syscall auditing is interested in the resources/details of *one* syscall
> > event at a time (from audit_syscall_entry to audit_syscall_exit),
> > logging the subject attributes of a process (who) doing what (which
> > syscall) to what (frequently a file).  Depending on the syscall, there
> > could be any number of auxilliary records to that event that help fill
> > in the whole picture that interests us.
> > 
> > So which file are you talking about that "would indeed create a path"?
> 
> The files in /sys/kernel{/debug}/tracing/events/*

These appear to be the null PATHs I'm looking for.

So these appear to be the PATH records that are being seen, mounted on
/sys/kernel{/debug}/tracing/, but showing up as anonymous because the
path to the mount point is unknown or unavailable in the audit_names
list at the time of the syscall.

Could that tracefs instance have been populated but not yet mounted at
the time the module was loaded on boot? (fs-nfs4, nfsv4)

> A module may connect "trace events" to parts of its code. When a module
> gets loaded, virtual directories and files are created with respect to
> the events within the module. When the module is unloaded, those files
> are removed.

Can the availability of debug or trace points in a module be forced off
by a user to avoid or limit the problem?

Is the availability of these trace points a build time or run time switch?

Is there any security liability to having those trace points available
in the filesystem in terms of control or information leakage?  (Sounds
like yes.)

> > > > 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.  
> > > 
> > > If there's a bug in the kernel code, then I'm sure there's probably a
> > > way to abuse it.
> > > 
> > > I also don't believe it should be ignored, which is why I'm asking
> > > these questions. I want to know what exactly is being looked at, and
> > > what is considered "OK" and what isn't.  
> > 
> > That one is harder to answer and depends on the syscall and its
> > potential to influence system behaviour, or to exfiltrate information.
> > 
> > > Now loading modules can indeed create files and directories. Is this
> > > something that the audit system needs to understand?  
> > 
> > Does it create them immediately in that syscall?  Or does it make that
> > path available for other operations later?
> 
> Not sure what you mean here. The files are created, but to use them,
> another process needs to do an open and write to them.

Ok, so I think I've concluded that these are the same files.

So the system is working as intended.  The next question is how do we
address the issue, perhaps by answering the three questions above.

> The inodes and dentrys are created. But the process should not have any
> file descriptors created associated with them.

It doesn't need to.  I assume a module could open a file from within the
kernel to read it or write it and then close it, all within the module's
init routine and be done by the time the syscall finishes.

> -- Steve

- 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

Powered by blists - more mailing lists