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 <[email protected]> > > > > --- > > > > > > > > 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 <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
