3 ms·

A personal firewall is nothing more or less than a layer-7 firewall which rules you can (somehow) manage as user you are logged in with, with a nice GUI. There

by Fnoord 6y ago

A personal firewall is nothing more or less than a layer-7 firewall which rules you can (somehow) manage as user you are logged in with, with a nice GUI. There is Open Snitch [1] (plus forks/patches) for Linux, if you're after such. [1] https://www.opensnitch.io https://www.opensnitch.io

qwerty456127 6y ago
The page you have linked to won't even open. I have witnessed a number of attempts to replicate LittleSnitch on Linux, none of them went far enough to anything near a usable product quality. You need to implement at least some functionality on the kernel level (what LitleSnitch does with a kernel extension) for this, most of the people who care about desktop apps on Linux (me included) lack kernel developer skills.
- Fnoord 6y ago
  True, its not production quality. Here is an actively developed fork/repo of OpenSnitch [1] [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch
- gus_ 6y ago
  did you try tinysnitch [0], opensnitch fork [1] or Douane [2]? [1] works pretty well for me. [0] https://github.com/nathants/tinysnitch https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/ https://github.com/Douane/Douane/
vetinari 6y ago
Editing the rules as a user with a GUI is the easy part. The more difficult parts are in details: - how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. - what happens to the connection while the firewall is waiting for the user input in the UI? Linux apps handle long timeouts badly - what happens to other connections while the firewall is waiting for the user input in the UI? Right now, unfortunately, whey would have to wait too. - LittleSnitch does interesting heuristic wrt hostname/ip translation - you can get different (or no) hostname via reverse query than the application asked for. You need to monitor what each application is resolving and what answers it get. If you get same IPs for different hostnames for a single application, all bets are off, only application knows which one it connects to (you can eventually learn with DPI, but for that it might be too late). For applications with their own resolvers using DoH/DoT, tough luck. The first problem could be solved at the level of sandbox runtimes (i.e. flatpak et al), i.e. when you know, that the application is running in the namespace belonging to specific flatpak package, you would present that as that specific application, they cannot lie about that anymore but the price is, that you can handle only sandboxed apps; for scripting and so on you still have to find how to distinguish specific instances. For all the other problems, you would have to figure them out.
- jfrunyon 6y ago
  /proc/.../exe exists. ETA: and most Linux apps will just sit there blocking in the syscall, or at the very worst, retry/show an error/crash.
- saagarjha 6y ago
  > how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. iTerm actually ran into this very issue (using the equivalent macOS APIs) and had to treat it as a security bug because the results were controllable in-process as well. And it also ran into the problem of how to deal with interpreters. It basically ended up being all ripped out and the API was redesigned to require authentication tokens rather than trying to figure out a meaningful source for a process.

by Fnoord 6y ago

qwerty456127 6y ago

The page you have linked to won't even open. I have witnessed a number of attempts to replicate LittleSnitch on Linux, none of them went far enough to anything near a usable product quality. You need to implement at least some functionality on the kernel level (what LitleSnitch does with a kernel extension) for this, most of the people who care about desktop apps on Linux (me included) lack kernel developer skills.

Fnoord 6y ago
True, its not production quality. Here is an actively developed fork/repo of OpenSnitch [1] [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch
gus_ 6y ago
did you try tinysnitch [0], opensnitch fork [1] or Douane [2]? [1] works pretty well for me. [0] https://github.com/nathants/tinysnitch https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/ https://github.com/Douane/Douane/

vetinari 6y ago

Editing the rules as a user with a GUI is the easy part. The more difficult parts are in details: - how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. - what happens to the connection while the firewall is waiting for the user input in the UI? Linux apps handle long timeouts badly - what happens to other connections while the firewall is waiting for the user input in the UI? Right now, unfortunately, whey would have to wait too. - LittleSnitch does interesting heuristic wrt hostname/ip translation - you can get different (or no) hostname via reverse query than the application asked for. You need to monitor what each application is resolving and what answers it get. If you get same IPs for different hostnames for a single application, all bets are off, only application knows which one it connects to (you can eventually learn with DPI, but for that it might be too late). For applications with their own resolvers using DoH/DoT, tough luck. The first problem could be solved at the level of sandbox runtimes (i.e. flatpak et al), i.e. when you know, that the application is running in the namespace belonging to specific flatpak package, you would present that as that specific application, they cannot lie about that anymore but the price is, that you can handle only sandboxed apps; for scripting and so on you still have to find how to distinguish specific instances. For all the other problems, you would have to figure them out.

jfrunyon 6y ago
/proc/.../exe exists. ETA: and most Linux apps will just sit there blocking in the syscall, or at the very worst, retry/show an error/crash.
saagarjha 6y ago
> how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. iTerm actually ran into this very issue (using the equivalent macOS APIs) and had to treat it as a security bug because the results were controllable in-process as well. And it also ran into the problem of how to deal with interpreters. It basically ended up being all ripped out and the API was redesigned to require authentication tokens rather than trying to figure out a meaningful source for a process.