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&gt; 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?