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

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.

paul moore