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

[Feature Request] Add ability to select a single file for rules, ontop of a directory. #1015

Open
TriMoon opened this issue Aug 13, 2023 · 0 comments
Labels
feature a whole new feature

Comments

@TriMoon
Copy link

TriMoon commented Aug 13, 2023

Summary:

According to https://github.com/evilsocket/opensnitch/wiki/block-lists#limiting-to-what-domains-an-application-can-connect-to we have to select a directory in which any filename can be placed to list rules.

The current functionality is nice for downloaded rules, with unknown filenames, but it is absurd for admin-created rule files, because an admin creates files them self and place them alongside other files that might contain rules to allow/reject/deny.

So to be backward-compatible, i suggest to add functionality to check if the selection is a directory or a single file.

  • Directory = Old behavior.
  • Single file= Only use that specific file for the rule.

Example use-case:

  1. We have a single app that we want to control.
  2. We want to create explicit rules to allow some destinations using reExp.
  3. We want to create explicit rules to reject some destinations using reExp.
  4. We want to create a catch-all to deny unknown destinations.
  • Current way:
    Create multiple directories containing single files. (This is VERY ugly for an admin !)
  • Enhancement:
    We want multiple files to be kept inside a single directory, that can be selected in separate rules.
    Example file paths:
    • appX/allow-re.txt
    • appX/reject-re.txt
    • admin-rules/appX-allow-re.txt
    • admin-rules/appX-reject-re.txt
    • admin-rules/appY-allow-re.txt
    • admin-rules/appY-reject-re.txt
@TriMoon TriMoon added the feature a whole new feature label Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a whole new feature
Projects
None yet
Development

No branches or pull requests

1 participant