USBGuard
Ruleset file updates blocked since #282
When appending a rule to the rule set, an error is returned: $ usbguard append-rule "allow" IPC ERROR: request id=1: FileRuleSet saving: /etc/usbguard/rules.conf: Read-only file system
I believe the recent sandboxing implemented in #282 broke this feature.
This can be fixed by appending /etc/usbguard/rules.conf to the line ReadWritePaths=. But perhaps a better fix would be to move the writable configuration under /var, because root file system may be read only for other reasons and then changing rules would work also in that case.
Thanks. As you suggested, I would prefer to have the writable configuration in a different path than the static rules. @dkopecek what was the reasoning for making the append-rule command change the rules.conf (when it wasn't the case in previous (< 0.7.0) versions)? (See also PR #285)
@tweksteen @topimiettinen I agree, having the policy management commands modify policy in /etc is stupid/too simplistic. What about adding /var/usbguard/rules.conf via new configuration option DynamicRuleFile or WrittableRuleFile. usbguard-daemon would first load the static rule file /etc/usbguard/rules.conf (and in the future maybe also from /etc/usbguard/rules.d/) and then load /var/usbguard/rules.conf (if set). The CLI commands would modify only the policy in /var. That way we keep backwards compatibility with existing setups.
The CLI commands would modify only the policy in /var.
please don't do that. Other software components such as systemd or udev don't have configuration files for users outside of /etc. Software behaving differently probably exist, but we should really work towards making system more stateless and containing mutable artefacts. As of today, we aim for containing user editable configuration in /etc.
The CLI commands would modify only the policy in /var.
please don't do that. Other software components such as systemd or udev don't have configuration files for users outside of
/etc. Software behaving differently probably exist, but we should really work towards making system more stateless and containing mutable artefacts. As of today, we aim for containing user editable configuration in/etc.
Don't do what exactly? Keep modifying whatever is set in RuleFile? Drop that altogether (append-rule, remove-rule, ...)?
sorry for not being clear. I mean actively writing configuration data outside of /etc/.
Although, the more I think about it, you could consider the rule file to be an artefact of the running daemon and thus it being state it maintains.
But "append-rule" sounds more like configuration than managing state. Note how systemd distinguishes State and Configuration: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=
And AFAICS, the rule files as they are today are meant to be edited by system administrators. As such it sounds /etc is the place for those. Maybe the above mentioned systemd directives help to overcome this particular issue.
"static rules", which are possiby set by ISVs, should go in /usr or /lib or so. Note how udev stores "static" rules in /lib/udev/rules.d/ while loading configurable rules from /etc.