I love Little Snitch. I hate Little Snitch.<p>The first time I installed and ran Little Snitch, I was pretty much flabergassted at how chatty my system was. Just constantly being presented with requests to the point that made it impossible to work. I loved learning how prevelant E.T. phoned home.<p>But then as I was just constantly inundated with those requests, I hated having to constantly deal with it. Now it's time to whitelist/authorize/etc. But do I really want to blanket OK something just because I'm annoyed? What does one do to stay sane and safe?<p><disables Little Snitch> securely places head back in sand<p>Little Snitch is the single program to illustrate all of the scary websites/blogs/etc of how shitty companies are about their "free" software and other shenanigans that devs play and from some "legit" companies.<p>I love Little Snitch and I hate Little Snitch, and it's not their fault.
Until Linux duplicates that BSD tagging of inbound packets to process ID, no Linux-derivative LittleSnitch is going to match macOS/BSD-variant LittleSnitch’s capability set of detecting WHICH application having received a network packet.<p>Given the above, sandboxing with namespace nftable is still required for ultimate inbound security (I am looking at you, systemd).
What exactly is the use case of such an application firewall?<p>I mean I get what it is supposed to do, but if I already have a means of blocking certain spam/telemetry URLs that I don't want (via etc/hosts, or PiHole), is there any <i>real</i> benefit of using an application firewall on top?<p>As others have said, micro-managing all these connections is not really feasible in most cases. And if I have a domain I don't trust, I can just globally block that.<p>What are some real-world use-case scenarios of a domain that I want to block for one application, but not generally for all applications? It sounds cool in theory to be able to fine-tune all that on an application basis, but is this actually useful/sensible in practice?
this is a really great project.<p>if you haven’t heard of libnetfilterqueue, this is what it’s for. it’s really good. tremendous thanks to the author for introducing me to it via this project.<p>the main problem with libnetfilterqueue is that it doesn’t have pid information. you have to look that up in /proc or via a hashmap maintained by ebpf. either method has issues.<p>an unexplored alternative, afaik, is seccomp with userspace filtering[1]. then you get pid information and direct control of syscalls. this may still need to be paired with libnetfilterqueue depending on implementation.<p>1. <a href="https://lwn.net/Articles/756233/" rel="nofollow">https://lwn.net/Articles/756233/</a>
Anyone aware of userspace application firewalls that be run for a process from cli? No requiring system level configs/packages or root privileges.<p>Something like this:<p><pre><code> app_firewall --block all --allow www.google.com ./my_untrusted_application
</code></pre>
Or like this:<p><pre><code> app_firewall --rules my_employer_network.conf ./untrusted_employer_application
</code></pre>
Then you can do cool stuff like:<p><pre><code> app_firewall --block microsoft.com qemu my_dirty_windows_virtual_machine.qcow</code></pre>
How does it compare to Bubblewrap? I tried it to test Windows software that I don't trust under WINE and it worked, but a few times the sandboxed program wouldn't work although it would when run under a non networked machine, so I thought the sandboxing was also affecting Unix sockets, that is, IPC.<p>Command used was: "bwrap --bind / / --dev /dev --unshare-net -- exe_name"
There is also eBPFSnitch, though it hasn't been updated in a while. It uses eBPF for packet filtering.<p><a href="https://github.com/harporoeder/ebpfsnitch" rel="nofollow">https://github.com/harporoeder/ebpfsnitch</a>
Also see <a href="https://objective-see.org/" rel="nofollow">https://objective-see.org/</a> and their LuLu tool if you're on MacOS.
So Wireshark but with connection permission toggles... Why does anyone need this on Linux? You can already block domains you know are malicious in the hosts file or use a personalized DNS resolver for that. Or am I missing something?
Unfortunately without sandboxing, these sorts of tools just add an extra layer of maintenance to your system for a false sense of security [1, 2].<p>This can actually be harmful for less experienced Linux users who may trust something like this to keep them safe for running random scripts, especially since I see this tool often recommended for such a use case.<p>[1] <a href="https://news.ycombinator.com/item?id=22208223" rel="nofollow">https://news.ycombinator.com/item?id=22208223</a><p>[2] <a href="https://news.ycombinator.com/item?id=14254679" rel="nofollow">https://news.ycombinator.com/item?id=14254679</a>