AuditRule Questions

Joe Wulf joe_wulf at yahoo.com
Tue Jan 19 18:11:56 UTC 2021


 Steve,
On Tuesday, January 19, 2021, 11:57:03 AM EST, Steve Grubb <sgrubb at redhat.com> wrote:  
 > On Tuesday, January 19, 2021 8:15:33 AM EST Joe Wulf wrote:
> > 1. In audit rules 2.8.5 (front portion of the rules):> > > > ## Unsuccessful file access (any other opens) This has to go last.> > -a always,exit -F arch=b32 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a> > always,exit -F arch=b64 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a> > always,exit -F arch=b32 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM-a> > always,exit -F arch=b64 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at  -F exit=-EPERM> > Whereas in audit rules 3.0, the same portion of the same rules looks like:> > -a always,exit -F arch=b32 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES-a> > always,exit -F arch=b32 -S> > open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM-a> > always,exit -F arch=b64 -S> > open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES-a> > always,exit -F arch=b64 -S> > open,truncate,ftruncate,creat,openat,open_by_handle_at  -F exit=-EPERM> > > > The ordering of the syscalls differs between the two, as well as the> > sequential order of the rules themselves. I better understand that the> > first audit-rule matched 'wins'.-  Please help me understand the reason> > for the change in sequence, but also for the change in the order of the> > syscalls (i.e. between 2.8.5 and 3.0).> > There were several 3.0 alpha releases. I'm not sure which one you are calling > 3.0. Because I can't find an exact match. Based on the text above, I do not > see the syscall ordering changed at all. The only thing that I see is in > 2.8.5 they are grouped by exit code whereas 3.0 is grouped by arch. Since > this group of rules all have the same key, they are working as a team. That > means that what matters is the placement of this group of rules relative to > other groups of rules is what matters. In both cases a syscall can ever only > match one of them - the exit code either is or isn't EPERM, it either is or > isn't b32.> 
> <snip>> 
> -Steve
Steve,
Thank you for the wealth of feedback.  All very useful.  Thank you.
I pulled v3.0 of the audit rules out of RHEL 8.3.
In the sections I referenced, for v2.8.5 the syscalls for b64 are in the order of:open,create,truncate,ftruncate .....
in v3.0, they are in the order of:open,truncate,ftruncate,create ....
Since, as you say above, the audit rule can only ever match one syscal.... I'm now understanding the actual order of the syscall's is no longer relevant on such lines (from an auditing perspective)?
In general for a any given system being run and audited by either set of rules, the end result I suspect would be the same.The challenge could come in when certain vulnerability tools assess the system, and do so by seeking an exact match of rule syntax.
Thank you.
R,-Joe Wulf
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20210119/150aeccf/attachment.htm>


More information about the Linux-audit mailing list