Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to implement multiple rules.conf files #224

Open
fcpp31 opened this issue Feb 25, 2018 · 9 comments
Open

Request to implement multiple rules.conf files #224

fcpp31 opened this issue Feb 25, 2018 · 9 comments

Comments

@fcpp31
Copy link

fcpp31 commented Feb 25, 2018

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
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Member

radosroka commented Aug 18, 2019

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Contributor

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
Copy link

lucab commented Dec 13, 2019

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
Copy link

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
Copy link
Contributor

+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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants