Re: Hundreds of null PATH records for *init_module syscall audit logs

+++ Richard Guy Briggs [06/03/17 16:49 -0500]: >On 2017-03-03 19:22, Paul Moore wrote: >>On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: >>> On 2017-02-28 23:15, Steve Grubb wrote: >>>> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: >>>> > Sorry, I forgot to include Cc: in this cover letter for context to the 4 >>>> > alt patches. >>>> > >>>> > On 2017-02-28 22:15, Richard Guy Briggs wrote: >>>> > > The background to this is: >>>> > > https://github.com/linux-audit/audit-kernel/issues/8 >>>> > > >>>> > > In short, audit SYSCALL records for *init_module were occasionally >>>> > > accompanied by hundreds to thousands of null PATH records. >>>> > > >>>> > > I chatted with Al Viro and Eric Paris about this Friday afternoon and >>>> > > they seemed to vaguely recall this issue and didn't have any solid >>>> > > recommendations as to what was the right thing to do (other than the >>>> > > same suggestion from both that I won't print here). >>>> > > >>>> > > It was reproducible on a number of vintages of distributions with >>>> > > default kernels, but triggering on very few of the many modules loaded >>>> > > at boot time. It was reproduced with fs-nfs4 and nfsv4 modules on >>>> > > tracefs, but there are reports of it also happening with debugfs. It >>>> > > was triggering only in __audit_inode_child with a parent that was not >>>> > > found in the task context's audit names_list. >>>> > > >>>> > > I have four potential solutions listed in my order of preference and I'd >>>> > > like to get some feedback about which one would be the most acceptable. >>>> >>>> 0.5 - Notice that we are in *init_module & delete_module and inhibit >>>> generation of any record type except SYSCALL and KERN_MODULE ? There are some >>>> classification routines for -F perms=wrxa that might be used to create a new >>>> class for loading/deleting modules that sets a flag that we use to suppress >>>> some record types. >>> >>> Ok, I was partially able to do this. >>> >>> If I try and catch it in audit_log_start() which is the common point for >>> all the record types to be able to limit to just SYSCALL and >>> KERN_MODULE, there will already be a linked list of hundreds to >>> thousands of audit_names and will still print a non-zero items count in >>> the SYSCALL record. This also sounds like a potentially lazy way to >>> deal with other record spam (like setuid BRPM_FCAPS). >>> >>> If I catch it in __audit_inode_child in the same place as I caught the >>> filesystem type, it is effective for only the PATH record, which is all >>> that is a problem at the moment. >>> >>> It touches nine arch-related files, which is a lot more disruptive than >>> I was hoping. >> >>Blocking PATH record on creation based on syscall *really* seems like >>a bad/dangerous idea. If we want to block all these tracefs/debugfs >>records, let's just block the fs. Although as of right now I'm not a >>fan of blocking anything. > >I agree. What makes me leery of this approach is if a kernel module in >turn accesses directly other files, or bypasses the load_module call to >load another module from a file and avoids logging. AFAIK load_module is *the* entry point for module loading, it is where all the setup occurs in order for a module to be properly set up and registered in our internal data structures (e.g the global modules list). If a module wants another module loaded, it can request for it to be loaded via request_module(), which punts the request to modprobe in userspace to load the module in question, but I'm not sure if that's at all related to this null PATH record issue.

Jessica