Not sure if it was selinux, or apparmor. But I really appreciated when I opened a PDF I got a popup saying "The PDF reader is trying to open an outgoing connection to foo.adobe.com". Turns out some PDFs have tracking magic in them and report to home base, I would have never known. This kind of thing seems like a common security restriction for android apps, but much less so for desktop apps.
It is a great feature; Windows Firewall Control does notifications nicely, too, and it's now freeware since bought by Malwarebytes.
On Android I recall that this control was taken away from users long ago. Blocking an app's network access blocks its ads, after all. The argument was that without any other permissions, an app's potential for harm with internet access is limited. Only in Android 11 have I seen this restored, and I only noticed after digging around the settings after the major version OTA update. i.e., I don't get notified. Apps have internet access by default.
On that note, I recall when Windows started coming with a firewall, people like Steve Gibson criticized its allow-all-outbound-by-default rules as making it nearly useless to protect less savvy users.
Nftables and Linux still hasn’t been able to filter —-> INBOUND <—-packets by Process ID, by Process group ID, by process name, and possibly by process namespace.
It is said in the article says you have to get your hands dirty, but yeah I can not see any easy way. Researching the naive way I got stuck in eBPF filters, and that will also fail with doing process/socket lookups since several applications can listen on a port. I guess you can filter on delivery to the application in some way..
An ingress packet will end up mapped to a process by the OS, so it should be feasible to extend a network rule to include the process based information:
Example Rule: allow process "squid" with shasum "1a2b3d4" running as user "squidy" to receive packets via "TCP" port "3138"
> How can the wanted functionality not be implemented by applying filters to the port bound by the process?
A port filter is dumb in a sense, anything can be underneath. It's fine for something like a web server, run by root, on a couple of consistent ports, running all the time. Process based rules might be more useful for services with dynamic port ranges or real people running random things.
Your questions concept may be the easiest way around the issue in Linux world. It could be easier to have BPF monitor process start/stop and port open/close changes and modify the allowed ingress to suit the process based ruleset than it is to attempt the lookup purely on the inbound path. Due to the multi process listening feature, the connection > process mapping info may only be available after it's happened which might not be the best point to firewall something.
> Really, what we are talking about is this: what if, when Zoom sent telemetry to Facebook without your authorization or knowledge apparently because they used some library and didn't realize it did that, your host firewall told you that this random application was shipping your most personal secrets directly to Mark Zuckerburg and, even better, prevented it doing so until you considered the question?
Never used it myself, only remembering it from my thesis days about essentially the same topic. I see they made the jump away from Python to Go and I'm also somewhat surprised the project is not only still active, but appears to have matured nicely. Guess I'll have to check it out now!
I'm using OpenSnitch for over 2 years now on my desktop systems. Can fully recommend.
I've set the default timeout to 30 seconds so I have time to decide/chime in, and the default action to one-time deny so it doesn't mess up my rules when I'm not at the computer.
Compared to previous Linux firewalls it's able to filter by binary and command line path (e.g. is able to differ between python server.py and python malware.py), which I think is pretty amazing.
Though I have to say due to the nature of wine, allowing things in nice rules there is a little harder (cause everything uses rundll32.dll anyways :-/ ).
Those already exist, eg. littlesnitch on mac. As it relates to this problem though (ie. zoom), such program would get annoying pretty quick, because they'll be connecting to random IPs every time (different relay servers/peers), so you eventually get tired of the alerts and whitelist everything.
I think the alerts would have to be at a higher level hierarchy than plain URLs or domains.
I'm imagining a categorized whitelist of domains based on purpose (essential, telemetry, ads) which the user would choose from at first run, and the program would just block the other domains without asking again and again.
I find huge value in using these as a blacklist - this won't protect against a zero-day or unknown malware, but it will absolutely protect against the known, repeat offenders. Having all Facebook and Google domains & IPs blacklisted will already do wonders for your privacy. You can whitelist the browser if you need to access such services while making sure trackers in other apps still can't talk to them.
ZoneAlarm did this back in the day. I was puzzled even back then about why so many applications wanted to dial out to this address or another. Today it would probably scream non-stop.
We take this a step further with our aspnetcore webapps.
In addition to your typical network security appliances and host firewalls, we've written middleware that executes as the very first item in the pipeline. It has a strict list of urls that are allowed as well as the opportunity for session-level auditing (i.e. when is the last time we saw this user log in from this starbucks). Depending on policy, a request could be dropped or even silently routed into a bullshit honeypot environment, which in this case is hypothetically an instance of MockDomainService running in the same process.
