How to discriminate between connexions that are using a common "proxy" (Python) to reach internet?

[Ileca]

OpenSnitch is an "application firewall" but it fails in front of something like Python that is used by MANY applications to connect to the internet. It is therefore impossible to discriminate between those calls that are all made through /usr/bin/pythonx.x. Examples are Lutris, Bottles, Deluge, even the PPA system uses Python to connect to launchpad.net.
You can't use hosts to filter because two applications might use the same Github url and you want one to not go through. Or like Deluge, it connects to pretty much everything. You can't use ports because like Deluge, it uses random ports. Well, you can configure that but what prevents a rogue application from hogging some legit port? In the end, I use this "application firewall" for a reason, not to go back to old hosts/ports filtering.

Anyway, what to do in this situation? My list of rules for Python is growing by the day and they are filtered against hosts. Of course, I can't use Deluge because of that without whitelist the whole Python process.

[gustavo-iniguez-goya]

Hi @Ileca ,

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.

[Ileca]

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.

[gustavo-iniguez-goya]

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?

[Ileca]

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