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(a)redhat.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(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635