-
-
Notifications
You must be signed in to change notification settings - Fork 492
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
[Feature Request] Rule Groups #1078
Comments
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.
edit: a template for the default rule name would also be awesome |
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). How to create groups / add rules to groups:
When creating a new group a dialog will be displayed with these fields: Group name: Later on we can add options to the dialog / contextual menus:
That's interesting. The dialog for a new group could contain options to build the group name, like: Group name: |
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:
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? |
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) |
It complicates everything a little bit more. I'd prefer to only create one sub-level: Applications -> Firefox
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.
Yeah, I think it has worked well for rules.
Those rules will appear when selecting "Application rules", "Permanent" or "Temporary".
Let's start with something basic that can address the current problem, and in the future think about how to keep improving it :)
@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 Anyway, without refactoring the main window internals I don't think this is doable for now. I hope to start working it soon though. |
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:
The text was updated successfully, but these errors were encountered: