How to discriminate between connexions that are using a common "proxy" (Python) to reach internet? · evilsocket/opensnitch · Discussion #612 (original) (raw)

I usually filter by command line instead of only the process path, for example:

that way you only allow or deny that script or command in particular. Otherwise you'd allow everything that uses python3.

You must be logged in to vote

3 replies

Ok, I tried that and looking good so far.
Isn't it better as a default than by executable? I mean, if I started by allowing wget because I use it extensively, what prevents a virus from using it to download more malicious files? Same, if I am Python developer and I start by allowing it, then everything using it will have the go-ahead. This looks pretty dangerous because, the thing is, you don't know what will be used by what so you can never whitelist the executable alone.

On a side note, Opensnitch is not very ergonomic when it comes to selecting both from executable and command line. You can only choose one or the other on the prompt then you have to go to your rules, click on it to see the history and fail at copying the process or args because when you double click on the field, it's like the app wants you to rewrite the field (weird). You can copy the whole line but it's the whole line and the rule fields are tiny. Quite cumbersome.

I don't know why "by executable" is the default target (I didn't create this project), but yes, I think "by command line" is better for security reasons. I think there's no easy answer, maybe we set "by command line" as default and people start complaining about too much pop-ups. So far we haven't had any complain about this, and usually power users (like you) figure out how to personalize the app for their needs.

On a side note, Opensnitch is not very ergonomic when it comes to selecting both from executable and command line.

Noted 👍 We could fill up all the fields when editing a rule, but with the not-selected fields grayed out. what do you think?

I think this is not by default because this is something you understand the usefulness only with practice. By commands is counter intuitive. I specifically searched a firewall targeting applications and would have never thought of using one targeting commands.

We could fill up all the fields when editing a rule, but with the not-selected fields grayed out. what do you think?

Yes, that would be useful.
However, the main problem is the popup. You have two type of section: the checkboxes and the select. However, they do the same thing afaik. If you click both on the destination IP and on the domain in the select, you get a rule with only one filter: the destination IP/domain. The same with port and UID.
I don't understand why this is duplicated twice like that. All the select has over the checkboxes is "from this executable" and "from this command". Can't we have them added at the top of the checkboxes? I guess the lead thought that he had to enforce the use of one filter (or no rule could be created) and that is the select, but then he couldn't check other filters at the same time, that are the checkboxes. You can enforce the use of one filter without the select. Either

you don't enter a rule if no filter is used
you prevent the closure of the popup and warn the user with a red line that he forgot to choose one filter
you do that and warn him that next time he tries to close the popup without selecting a filter, no rule/a rule using the default filter will be created,
my favorite solution which is to prevent the unchecking of the last checkbox (there must always be one checkbox checked).

Answer selected by Ileca