AuditRule Questions

[Steve Grubb]

On Tuesday, January 19, 2021 1:11:56 PM EST Joe Wulf wrote:
>  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 the kernel, the syscalls in each rule go into a large bitmask so that all 
can be checked quickly. Ordering within a rule doesn't matter for syscalls. 
Otherwise, fields are checked sequentially from left to right. So, things that 
may be false most of the time should be located more to the left for better 
performance.

> 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.

That is a challenge. That is what drove splitting up the ospp rules into 
individual files.

-Steve