[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170307130409.40d1963c@gandalf.local.home>
Date: Tue, 7 Mar 2017 13:04:09 -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 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.
>
> 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.
Now loading modules can indeed create files and directories. Is this
something that the audit system needs to understand?
-- Steve
Powered by blists - more mailing lists