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]

Date:   Tue, 7 Mar 2017 13:34:47 -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 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"?

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

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