Bug ID 1226418
Summary yast2-audit-laf rules are not preserved across reboots
Classification openSUSE
Product openSUSE Distribution
Version Leap 15.6
Hardware x86-64
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component YaST2
Assignee yast2-maintainers@suse.de
Reporter nvbugs@hhecht.e4ward.com
QA Contact jsrain@suse.com
Target Milestone ---
Found By ---
Blocker ---

With yast2-audit-laf-4.6.0-150600.1.2 on a fresh Leap 15.6 install:
The Yast audit module provides a tab "rules for 'auditctl'" that allows one to
edit the audit rules for the system.  Unfortunately, any changes made here are
lost on reboot, and are thus somewhat useless (and confusingly so).

The reason is that augenrules.service runs augenrules --load.  The manpage
says:

...merges all component audit rules files, found in the audit rules  directory,
/etc/audit/rules.d,  placing  the merged file in /etc/audit/audit.rules

I.e., it overwrites /etc/audit/audit.rules, as this is not part of the merge
set.  Yast loads from and saves to audit.rules only, so it is essentially
ephemeral.

This is clearly wrong, but I am not sure what the correct behavior here should
be.  If Yast edits e.g., /etc/audit/rules.d/yast.rules, then users will falsely
get the idea that they are editing all the rules, rather than just some of
them.  This is likely to be confusing in a different way, especially as the
default configuration contains "-a task,never", which disables all syscall (and
thus, even more confusingly, filesystem watch) rules.  The alternative would be
to continue to edit audit.rules but disable augenrules.service.  In the latter
case, rules.d should probably not be part of the package, as it would be
ignored.  Or perhaps yast can only display a warning, instead of the edit
widget, if there is anything in rules.d and augenrules.service is enabled? 
None of this seems fully satisfactory.

The underlying problem is how the audit software handles configuration files,
of course: augenrules is both less flexible and distinctly un-Linuxy compared
to e.g., the #includedir of sudoers.  Changing this would probably be confusing
in a yet a different way, however.


You are receiving this mail because: