[RFE] rules.d: please support overlaying and merging rules from /usr, /run, and /etc

[lucab]

This is a feature request for some new userspace logic doing rules-lookup in a more advanced way, in augenrules OR auditd.

In the context of stateless systems and immutables OS (e.g. CoreOS flavors of Redhat and Fedora, RHCOS/FCOS), it is worth to leave the content of /etc under exclusive ownership of the user, and move all system defaults to an immutable and OS-owned location under /usr.

To exploit the full potential of that, it would be helpful that auditd OR ausgenrule would start looking up rules fragments in the following hierarchies (in order of increasing priority):

• vendor defaults (packaged RO in /usr)
• runtime-volatile tweaks (generated into /run)
• user configuration (in /etc and normally not touched by OS packages)

Individual fragments would be ordered lexicographically by filename. Files with same name in higher priority directories can override those in lower directories.

For an example of software already having this kind of fragments-lookup logic you can have a look at the systemd suite, e.g. sysctl.d: https://www.freedesktop.org/software/systemd/man/sysctl.d.html#confd

[stevegrubb]

• There are no vendor defaults. Every site may have to follow NISPOM, PCI-DSS, STIG, Common Criteria, or other standards based configurations. It really varies a lot on what is required. I can't think of anything in common. There are also users that do not use auditd at all. So any vendor defaults would make them unhappy.
• There are no runtime-volatile tweaks. Ever.
• User configuration. Auditd respects this. It always has.

I don't know if there is anything to do here.

[lucab]

@stevegrubb thanks for the quick feedback! If you don't mind I'll quote-reply, as your terse answer makes that easier. Before getting to specific points, I fear I used ambiguous wording so there is possibly a fundamental misalignment to clear.

Here "vendor" means "whoever is assembling an OS image according to their specific requirements", which in many cases is a third-party (i.e. neither me nor you). To be explicit, I'm not requesting anybody here to define a set of generically-ok rules.

There are no vendor defaults. Every site may have to follow NISPOM, PCI-DSS, STIG, Common Criteria, or other standards based configurations. It really varies a lot on what is required. I can't think of anything in common.

I'm not expecting auditd upstream developers to define universal defaults (see comment above).
Specifically, your first point/sentence is not true. Each vendor may indeed define their own defaults, based on their own requirements. For clarity, some examples:

• Fedora may need to have a specific distro-wide default. This is, in fact, already happening under the masking of cp to /etc/audit/rules.d/audit.rules via %post logic.
• RHCOS may get a requirement to default-install some container-related rules (e.g. some content akin to 41-containers.rules one).
• different consumers/customers should be allowed to define their set of OS-default rules, when assembling an immutable OS image.

There are no runtime-volatile tweaks. Ever.

Fair feedback. To my experience, I've had to use runtime-volatile tweaks for systemd services only on few and odd occasions. I trust your assertion that no odd cases exist for auditd, and I'm fine if you prefer to take this point out of this discussion.

User configuration. Auditd respects this. It always has.

Indeed, and appreciated! The first part of this statement however is not as strict as it seems. The current /etc/audit/rules.d structure is mixing OS-defaults and user-configuration (see Fedora example above), which are two kinds of content with different lifecycle and ownership.
This ticket is exactly a request to support scoping them apart in a clear and user-familiar way.

[stevegrubb]

The sysctl.d system that you describe is additive. You can add sysctl settings. But there are some people that do not want audit at all. How would you override system defaults to be nothing? Or if the vendor defaults have 4 rules, how do you express to delete just one?

Also, the audit system rule ordering matters. Meaning that you need to stick specific rules in front of general rules to get the right match. For example,

-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access

Now what if the vendor loads the second rule in /usr? How could you fix that? Then what if rules almost match but not quite. For example, the first one has 3 syscalls and the last one has 4. How do we know the intent is to override when the match is fuzzy? And if we just insert the rule, then 3 out of 4 times, it will match the first and get whatever key is associated with that. This could throw off scripts that do analysis. Or what if the vendor has 10 rules and the admin wants to insert 1 rule in the middle of that list?

The only way to straighten this out and make it predictable by the system admin would be to delete all rules. But since each set of rules tends to start with -D, then do we match that or is it implied that means discard everything already processed?

To be honest, I am very skeptical that adding something this complex will have the same amount of benefit as the effort it takes to add this feature.

[teg]

@stevegrubb the way the override logic works in systemd should be able to accommodate what you describe.

If the distro ships rules /usr/lib/auditd.d/01-rules.conf, /usr/lib/auditd.d/02-rules.conf and /usr/lib/auditd.d/03-rules.conf, then they would be applied in lexicographical order. If the local admin wants to only override the rules in /usr/lib/auditd.d/02-rules.conf they would make their own version of that file in /etc/auditd.d/02-rules.conf which would completely replace the one shipped by the distro. If they don't want any rules applied at all they would make symlinks from each of /etc/auditd.d/01-rules.conf, /etc/auditd.d/02-rules.conf and /etc/auditd.d/03-rules.conf to /dev/null.

The overall goal (the way I see it) is for distros only to ship config in /usr (and never /etc) and for the admin never to need to edit /usr (but only /etc).

[stevegrubb]

I left this open because I wanted to reconsider this in the future. After thinking about this, there really are no vendor presets. Every setup is different. Because of that, if there were vendor presets, they'd be completely overridden in /etc. So, I'd like to just stay with the current setup.