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.