rework auditd_rules resource

[arlimus]

A typical use-case will have multiple rules listed. If we can find a better matcher than checking for a regex and also making giving the user nice output if the rule isn't found in the list. Let's find real-life LIST_RULES examples and use them for our docs. The current format may lead to confusion.

[srenatus]

Currently, the resource just exposes the lines it reads. The user experience would be way better if this supported something handier.

I'd also propose renaming the resource to audit, e.g.:

describe audit.syscall('openat') do
  its('action') { should eq('always') }
  its('list') { should eq('exit') }
end

describe audit.file('/etc/passwd') do
  its('action') { should eq('always') }
  its('perms') { should match('.*w.*') }
end

[srenatus]

Since there can be multiple rules relating to one syscall (or one file), I wonder what a good strategy for writing tests would be.

For example, two rules for open:

# auditctl -l
-a always,exit -F arch=b64 -S open -F success=0
-a always,exit -F arch=b64 -S open -F auid=1001

Now e.g. audit.syscall('open').rules could be

[
{ action: 'always', list: 'exit', fields: { arch: 'b64', success: 0 } },
{ action: 'always', list: 'exit', fields: { arch: 'b64', auid: 1001 } }
]

but then we cannot use RSpec's default include matcher, because it works with either Hashes or Arrays, not with Arrays of Hashes.

At the same time, we cannot use something like audit.syscall('open').actions, combining the separate rules, without losing information.

@chris-rock @arlimus: What's your take on this?

[arlimus]

I fully agree with your assessment of multiple rules, especially the part about the include matcher and similar ones. We should find a better way to expose those. I also think it's conceptually similar to other areas that have multiple very similar looking lines (e.g. iptables to a limited degree).

Let's consider use-cases:

• User wants to test if rules for syscall open exist; that could be done with auditd_rules.syscall('open').rules != empty
• User wants to consider inter-field comparisons and see if rule exists or doesn't: auditd_rules.syscall('open').field('auid=1001').rules != empty or just add action to the mix; basically moving the complicated parts further up the chain into a resource qualifier, instead of the matcher

(^^ first thoughts, naming prone to change; but the idea is to further specify the resource for what we are interested in )

Naming: Imho audit can quickly be confused with other mechanisms, while auditd is very specific. Let's tackle that separately.