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

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.