Request to implement multiple rules.conf files

[fcpp31]

Hello,
It would be nice to manage several rules.conf files (one specific for USB keys).
Is it possible to reload the rules.conf file(s) without restarting the usbguard service?
Regards

[marektamaskovic]

Hello,
I've got proposal:

• we create a directory /etc/usbguard/rules.d
• there will be multiple rulefiles
• only one implicit rule
• implicit rule has to be defined in usbguard.conf not in rules.conf / rules.d
• filenames in rules.d have to start with number [0-9][0-9].+ -> that sets the order of the file loading
• rules.conf will be first loaded and then every other file in rules.d by the order mentioned above
• enhance policy to contain multiple rule objects (each one represents one file)
• for interactive allowance there must be one ruleset only for added rules during the runtime

rules = [ruleset1, ruleset2, ruleset3, ...]
allRules = union(rules) # concatenate all rules to one
(found, rule) = search(allRules, device): # look for the rule (found is boolean, rule is rule)
if found:
    apply(rule, device)
else
    apply(implicit_rule, device)

[dkopecek]

@tammar96 👍 , I would also add:

• usbguard append-rule & related commands modify only /etc/usbguard/rules.conf (or whatever is set via usbguard-dademon.conf). i.e. the drop-in files are not modifiable via the CLI/D-Bus/IPC interfaces.

[radosroka]

What about using rules.conf OR content of rules.d directory. If rules.conf is not present and rules.d is empty, daemon will behave the same way like now without rules.conf -> runtime ruleset/policy.

What do you think about that?

[dkopecek]

@radosroka I don't understand exactly what use case you are describing. If rules.conf is not set, then (permanent) modifications via CLI/IPC should fail.

[tweksteen]

There is an order when processing the rules. Until now, it has been that the first rule matching is used. I believe we should strictly respect this design when implementing multiple rule files. Having a numeral prefix definitely helps, but we should keep the order in mind during the implementation (your search operation should be deterministic).

For deciding to which file a runtime addition should be targetting, we could use an extra parameter for the name of the rule (and default to rules.conf): usbguard append-rule -f 01-local.conf "allow"

[marektamaskovic]

I am bit confused right now.

I wrote:

for interactive allowance there must be one ruleset only for added rules during the runtime

@dkopecek wrote:

usbguard append-rule & related commands modify only /etc/usbguard/rules.conf (or whatever is set via usbguard-dademon.conf). i.e. the drop-in files are not modifiable via the CLI/D-Bus/IPC interfaces.

@tweksteen wrote:

For deciding to which file a runtime addition should be targetting, we could use an extra parameter for the name of the rule (and default to rules.conf): usbguard append-rule -f 01-local.conf "allow"

@dkopecek @tweksteen @radosroka Should append-rule be extended with option which file to be modified?

[lucab]

Additionally, from an OS vendor point-of-view, we would like to able to ship default rules as part of the OS and keep them separate from user customized ones.

An approach that works well here is the systemd one, where OS defaults go under /usr and user customization under /etc. Software logic then takes care of sourcing and merging from multiple locations.
The whole logic is better described at https://www.freedesktop.org/software/systemd/man/sysctl.d.html#confd with all the details.

[lordofhyphens]

Not just OS vendors have use for a rules.d style. I'm working on something that's partial OS customization and one of our requirements is to block all USB mass storage devices that don't match a particular vendor. We want to package our system as a series of RHEL RPMs that sit on top of RHEL7 to make our own lives easier, but any time you have to patch configuration files... we have a lot of extra complexity to deal with here.

[PureTryOut]

+1 to merging configs under /usr and /etc together from a distro packager point of view. We'd love to ship our distro configs (and usbguard's own configs) under /usr so they're never touched by the user and instead overwritten from /etc. Then we can always safely overwrite the distro config with a newer version without worrying about overwriting the user changes.