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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170307140931.58a7effb@gandalf.local.home>
Date:   Tue, 7 Mar 2017 14:09:31 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Richard Guy Briggs <rgb@...hat.com>
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 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/*

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.

> 
> > > 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.

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

-- Steve