[Feature Request] Rule Groups

[ItsDrike]

Summary:

I'd love to see a way to group a bunch of rules together under some collapsable box in the rules tab.

I (and I'd imagine a lot of other users too) am using opensnitch in a way where I block everything by default, only allowing the exceptions, and on most modern systems, this will result in dozens of rules being defined.

Currently, I use name prefixes like 0-SYSTEM-x, 5-APPLICATIONS-y, ... to distinguish between the rules, but this is not ideal. It would be much cleaner if we were able to create rule groups.

Concerns/Things to address:

• Right now, (afaik,) rules are being enforced in order based on the name & priority status, should groups affect this? i.e. will all rules in a group named 0-SYSTEM be enforced before those in a 5-APPLICATIONS group? Or will the enforcement order remain purely based on the individual rule names, regardless of the group? Perhaps this could be something we could select when creating a group, and internally, it could just work by prefixing the rule names with the group name.

[c33s]

i am also looking for a kind of autogrouping by application. would be nice to prefix the application path with the application name to easily find applications by name.

rules:
  firefox - /usr/bin/firefox:
     allow dns
     allow proxy access: proxy.example.com:1080
     allow https access 127.0.0.1
     ...
  wget - /usr/bin/wget:
    wget rules...

edit: a template for the default rule name would also be awesome

[gustavo-iniguez-goya]

Hi @ItsDrike @c33s !

Right now, (afaik,) rules are being enforced in order based on the name & priority status, should groups affect this?
Or will the enforcement order remain purely based on the individual rule names, regardless of the group?

just an idea:

In its simplest form Groups could be just a way to organize rules.

How it would work:

Naming a group "000-system" could contain the rules to easily filter by system rules, or naming it "Firefox" could group firefox rules (allow-firefox-80-443, deny-firefox, etc).
The daemon won't have the notion of "Groups", so the enforcement order will remain based on the rules' names and priority.

How to create groups / add rules to groups:

• by selecting a number of rules -> right click -> Create new group
• by right clicking on the "Applications rules" entry on the left panel -> Create new group
• from the Rules Editor, selecting a group from a combo box.

When creating a new group a dialog will be displayed with these fields:

Group name:
Rules of the group:
(...)
[Save] - [Close]

Later on we can add options to the dialog / contextual menus:

• to rename group's rules with the prefix/name of the group

i am also looking for a kind of autogrouping by application. would be nice to prefix the application path with the application name to easily find applications by name.

That's interesting. The dialog for a new group could contain options to build the group name, like:

Group name:
Append to the name:
[x] Application path
[x] DstPort
[x] Action
(...)

[ItsDrike]

I like this idea, indeed the daemon doesn't need to be aware of the groups, and I agree that the individual group rules should not have to follow group's priority, it would be really nice being able to have groups with both high priority and low rules, because the rules make contextual sense, but priority-wise, they don't necessarily make sense for the best speeds.

With the option to rename the rules in a group, auto-adding the group prefix, both groups where it does make sense to have the entire group at the same priority and where it doesn't will work properly, so I completely agree that this should be the way to do it.

I do have a few more questions on this:

• Will there be subgroups, i.e. a group in a group, like say Applications -> Firefox -> 052-Firefox-DNS?
• Can the same rule be a part of multiple groups? Considering the daemon doesn't need to be aware, it should be possible. Question is whether something like this would actually be beneficial, and if it wouldn't be confusing or even conflicting (what happens if both groups have the prefix option set?)
• How will the groups be ordered in the menu? purely by name? I suppose that's fine
• What if there are ungroupped rules? Where will those be in the ordering? Just next to the groups, sorted by name? Or will the groups always be before the ungroupped rules?

As for the options to autogroup by application/port/etc, it's not a bad idea at all, though I specifically don't think I'd use it, but sure, they can absolutely be implemented. However if they will be a thing, what about rules which are already in a group? Will those just not be checked, or will those rules be moved to this new autogroup? Or will it be possible to have the same rule in multiple groups, and solve it that way?

[NRGLine4Sec]

To my mind, groups should be assign per interface (related to [Feature Request] Add the ability to filter connections by the network interface · Issue #726 · evilsocket/opensnitch)

[gustavo-iniguez-goya]

Will there be subgroups, i.e. a group in a group, like say Applications -> Firefox -> 052-Firefox-DNS?

It complicates everything a little bit more. I'd prefer to only create one sub-level: Applications -> Firefox

Can the same rule be a part of multiple groups? Considering the daemon doesn't need to be aware, it should be possible. Question is whether something like this would actually be beneficial, and if it wouldn't be confusing or even conflicting (what happens if both groups have the prefix option set?)

Yes, I think a rule should be part of multiple groups. For example "system-group" and "systemd-group".

Renaming rules based on the prefix of a group would be optional, so users should be aware of the behaviour if one rule belongs to multiple groups. We could add a help button, explaining this and others behaviours.

How will the groups be ordered in the menu? purely by name? I suppose that's fine

Yeah, I think it has worked well for rules.

What if there are ungroupped rules? Where will those be in the ordering? Just next to the groups, sorted by name? Or will the groups always be before the ungroupped rules?

Those rules will appear when selecting "Application rules", "Permanent" or "Temporary".

As for the options to autogroup by application/port/etc, it's not a bad idea at all, though I specifically don't think I'd use it, but sure, they can absolutely be implemented. However if they will be a thing, what about rules which are already in a group? Will those just not be checked, or will those rules be moved to this new autogroup? Or will it be possible to have the same rule in multiple groups, and solve it that way?

Let's start with something basic that can address the current problem, and in the future think about how to keep improving it :)

To my mind, groups should be assign per interface

@NRGLine4Sec we could create groups also by operand, that way we could create any kind of groups: by iface.in/out, process.path, dest.ip, etc... you'd have to select it from the dialog to create groups, for example:

Group name: iface.out - eth0
[x] operand: iface.out == eth0

Anyway, without refactoring the main window internals I don't think this is doable for now. I hope to start working it soon though.