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

[Richard Guy Briggs <rgb@redhat.com>]

On 2017-03-07 11:20, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 11:00:27 -0500
> Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 2017-03-07 10:41, Steven Rostedt wrote:
> > > On Mon, 6 Mar 2017 22:39:54 -0500
> > > Richard Guy Briggs <rgb@redhat.com> wrote:
> > >   
> > > > >From the output I've seen, it doesn't look particularly useful, but it    
> > > > was useful to finally see the source of those huge numbers of PATH
> > > > records.  Here's an fpaste:
> > > > 	https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/  
> > > 
> > > Those are the files for the module's trace events that are created.
> > > 
> > > I'm still confused about what the issue is.  
> > 
> > The issue is the audit subsystem being overwhelmed by potentially
> > useless information.
> > 
> > The initial report was "there's a bunch of null PATH records, please
> > make them go away", which was anywhere from 500 to 6000 records.
> 
> I don't know the audit system and exactly what it is looking for. How
> does it deal with other virtual filesystems like procfs? Why is tracefs
> different?

The audit subsystem is looking, via sysadmin-crafted rules to notice
situations of interest, for details that could affect the integrity of
the system

This situation is specifically for syscall auditing.  Various syscalls
have expected numbers of accompanying PATH records, for example open(2)
would have directory and file PATH records, while rename(2) would have 2
directory and 2 file PATH records.  An open call on a file in /proc
could trigger a rule that was formulated to catch that type of activity
that lists its directory and its file PATH records, which would be fine.

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.

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.

> -- Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635