[PATCH] filter: add path filter with fstype

[Richard Guy Briggs]

On 2017-06-13 17:25, Steve Grubb wrote:
> Hello,
> 
> On Monday, June 12, 2017 10:45:50 PM EDT Richard Guy Briggs wrote:
> > On 2017-06-12 20:28, Steve Grubb wrote:
> > > This patch needs to be refactored to match the current count of error
> > > messages in err_msgtab.
> > > 
> > > What error message is emitted when run on a kernel that does not support
> > > the new filter?
> > 
> > -36 (which needs re-checking now that ghau12/ghau21pr has been reworked.)
> 
> And now that the other error message macros have been applied...

Re-spinning...

> > > On Tuesday, April 4, 2017 6:40:18 AM EDT Richard Guy Briggs wrote:
> > > > Tracefs or debugfs were causing hundreds to thousands of PATH records to
> > > > be associated with the init_module and finit_module SYSCALL records on a
> > > > 
> > > > few modules when the following rule was in place for startup:
> > > >         -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > > > 
> > > > Add the new "path" filter list anchored in __audit_inode_child() to
> > > > filter out PATH records from uninteresting filesystem types, "fstype",
> > > > keying on their kernel hexadecimal 4-octet magic identifier.
> > > > 
> > > > An example rule would look like:
> > > > 	-a never,path -F fstype=0x74726163 -F key=ignore_tracefs
> > > > 	-a never,path -F fstype=0x64626720 -F key=ignore_debugfs
> > > 
> > > Are we sure path is the best name for this filter? Is there something more
> > > precise like filesystem?
> > 
> > It is filesystem type that we are filtering, but there may be a use case
> > to filter on another factor later, so like the "type" filter that really
> > is the "exclude" filter, let's not make that mistake again.
> 
> What else could this filter have its hands on? Could it audit mounting/
> unmounting of certain file systems?

I wasn't thinking so much of the filter point, but other filter fields
(like auid=-1? or a mount sub-tree? or ...?).

> > I wrestled with that for a while and kept coming back to "path" filter
> > due to the fact that it was a path record that was affected. 
> 
> I don't like having path as a filter and path as a field option. Path is 
> getting too overloaded.

Granted.

> > At the moment it is only active on audit_inode_child, but I could
> > potentially see it being active on audit_inode as well.
> 
> I'd lean towards filesystem for the filter name.

I think I'm alright with that name.  I'll re-spin the patch and see if
anything jumps out at me in the process.

Another place this might be used is for the CWD record.

> -Steve
> 
> > > > Note: "always,path" will log the PATH record anyways and add latency.
> > > > 
> > > > See: https://github.com/linux-audit/audit-userspace/issues/15
> > > > See: https://github.com/linux-audit/audit-kernel/issues/8
> > > > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> > > > 
> > > > Signed-off-by: Richard Guy Briggs <rgb at redhat.com>
> > > > ---
> > > > 
> > > >  docs/audit_add_rule_data.3 |    3 +++
> > > >  lib/errormsg.h             |    5 +++++
> > > >  lib/fieldtab.h             |    2 ++
> > > >  lib/flagtab.h              |    2 ++
> > > >  lib/libaudit.c             |   26 ++++++++++++++++++++++++--
> > > >  lib/libaudit.h             |   10 ++++++++++
> > > >  lib/private.h              |    1 +
> > > >  src/auditctl-listing.c     |    6 ++++--
> > > >  src/auditctl.c             |   14 +++++++++++++-
> > > >  9 files changed, 64 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/docs/audit_add_rule_data.3 b/docs/audit_add_rule_data.3
> > > > index 2321f39..4867e8c 100644
> > > > --- a/docs/audit_add_rule_data.3
> > > > +++ b/docs/audit_add_rule_data.3
> > > > @@ -22,6 +22,9 @@ AUDIT_FILTER_EXIT - Apply rule at syscall exit.
> > > > 
> > > >  .TP
> > > >  \(bu
> > > >  AUDIT_FILTER_TYPE - Apply rule at audit_log_start.
> > > > 
> > > > +.TP
> > > > +\(bu
> > > > +AUDIT_FILTER_PATH - Apply rule at __audit_inode_child.
> > > 
> > > I don't think this is real clear. Maybe some others need touching up here
> > > as well. But we should say something someone with a casual knowledge of
> > > audit would understand.
> > 
> > Agreed.  How about "Apply rule when adding PATH auxiliary records to SYSCALL
> > events."
> 
> I updated this man page. It needs to say when its applicable, whether events 
> are normally accepted or blocked with no rule applied, and what the typical 
> use case is.

Ok, I see the other examples.

> -Steve

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635