How useful is it to prevent Linux applications from setting up any untrusted connections, and can it be done easily?

Question

Threat: your Linux machine gets compromised in some way (untrusted app, or compromised install package or update, or an app is compromised because of a vulnerability, etc.) and something on your system tries to "call home". So you want to prevent the call, basically neutralizing the vulnerability. You would spot it because you might see a notification saying "Gimp wants to connect to example.com on port 80: allow, allow once, deny?". I think it makes sense as a defense, doesn't it?

Yet apparently, if I'm not mistaken, there are no easy ways to do this on Linux, and no popular and trusted applications have been developed for this purpose (I googled and found several questions about this even here on stackexchange). Applications like AppArmor or SeLinux have been developed to control which files a process can use, but the same hasn't been done for network connections. On Windows such applications are very common and part of firewalls. Is there a reason the same has never been common on Linux? I don't think configuring the allowed network connections can be harder than configuring the allowed files in AppArmor or SeLinux, so it can't be a matter of usability.

I have to say maybe I've found a way to circumvent such methods. Most users will probably have to set a rule that allows the browser to connect to any host on port 80. Therefore malware could just try to copy itself inside the browser (patching it or as a plugin), and then it would be free to connect anywhere on port 80. Nevertheless, I don't think this makes trying to avoid untrusted connections totally useless. By the same reasoning, malware could patch AppArmor or its rules to be free of doing whatever it wants, but this doesn't make AppArmor totally useless.

Answer 1

You bring up a good point. EDR (Endpoint Detection and Response) has been created for this very reason. Vendors such as Crowdstrike do a great job at protecting endpoints. To my knowledge, most EDR software is developed to be invisible to the end user. Mostly because hosts are centrally managed by a administrator. A decent EDR would detect when a user downloads and runs a new application and you can track everything the program does, such as making outbound connections.

This type of software has to be very robust and smart so it is usually expensive. I would guess that is the most likely reason why it isn’t pre-installed on most Operating systems. EDR is available for most operating systems, Linux included.

To answer your question directly, it is very useful to monitor network connections from I trusted apps and it is usually difficult to do so effectively.

Answer 2

This is becoming more commonplace with the new sandboxing package formats - for example, the Snap package for GIMP doesn't or didn't have access to:

Removable Media

https://github.com/snapcrafters/gimp/issues/40

Printers

https://github.com/snapcrafters/gimp/issues/22

Network

https://github.com/snapcrafters/gimp/issues/32#issuecomment-410529372 (I'm not really sure if the error message there really corresponds to that, we've seen it in other contexts as well)

Now imagine distros where pretty much any software you're using is installed via such sandboxes, and you get towards what you are looking for. To my knowledge, it's not fine-grained enough to handle each and every single access yet, but there shouldn't be anything to prevent such permissions being given on a case-by case basis.

This will require some adjusting of user expectations, of course - as you can see, all of these were reported as issues because people thought the package was broken :)

Answer 3

There are a lot of points in your email, some of them are misconceptions.

Gimp wants to connect to example.com on port 80: allow, allow once, deny?

It looks like you want to transfer your experience from MS Windows to Linux. In Linux, it is difficult to associate network connections with the firewall. The firewall on Linux sits below the TCP layer - that means it can protect the TCP layer, but has limited visibility up the stack. Conversely, on MS-Windows the firewall sits above the TCP layer. But, of course, tools like netstat can asociate network sockets with processes, so its not impossible.

Have a look at netstat: How many of the sockets do you see belong to interactive user processes and which do not? How should the system programmatically decide whether to apply a default policy or ask the user?

Applications like AppArmor or SeLinux ... hasn't been done for network connections

Both SELinux and Apparmour can apply network controls, admittedly neither are very well documented. Further with network namespaces you can apply different firewall rules to different process groups.

there are no easy ways to do this on Linux,

It is surprisingly straightforward to do for incoming connections with TCP-wrappers (although it requires some knowledge of how the GUI implements session isolation and privilege separation). Its also relatively simple to control outgoing connections via (for example) squid although here its even more difficult to resolve the client application.

I suspect nobody has implemented a packaged solution to the problem because they don't perceive it as a problem. Perhaps you could right/write that.