Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LittleSnitch for Linux

obdev.at

Post reply on HN
Print view View original

381–390 of 489 posts

Re: LittleSnitch for Linux

#381

Post by grepfru_it »

m132 wrote: post #237
fsflover wrote: post #193

Earlier quoted context omitted.

It contains Firefox and Chromium. You are right that they may call home, but at least it's very limited and easily configurable. Could be too much for you but fine with me. Also Debian does change their config by default to minimize privacy issues: https://news.ycombinator.com/item?id=32582260

It's far from easy in the case of Firefox [0], and the last time I tried, some .mozilla.com domains would still get pinged. Chromium doesn't even have an official guide. The only options I found to be reliable are source-level patches, i.e. ungoogled-chromium and LibreWolf. Note that LibreWolf still leaves some of the stuff on for you to manually disable (dom.push.connection.enabled, extension updates). [0] https://s…

In firefox, goto about:config and search for url.

You're welcome.

Re: LittleSnitch for Linux

#382

Post by LoganDark »

tankenmate wrote: post #138
LoganDark wrote: post #96

Earlier quoted context omitted.

Something almost no firewalls get right is pausing connections (NOT rejecting them) until I've decided whether to allow or not. The only firewalls I've seen do this are Little Snitch for Mac, and Portmaster for Windows (before they made it adware / started locking existing local features behind the subscription).

I use Portmaster (on Linux) and I have never seen ads (either in the app or apps that get their DNS from Portmaster) on it. About the only thing I saw different between the free version and the base level paid for version was traffic history and weekly reports (and badges on Discord if that's your kind of thing).

Both used to be free. And you may not consider it advertising when unavailable features exist in the free UI just to tell you they're paid, but I do. Especially when they used to be free.

Re: LittleSnitch for Linux

#384

Post by dizhn »

bornfreddy wrote: post #379
dizhn wrote: post #303

Earlier quoted context omitted.

There is a ton of software that lives on because it matters to the developer(s) . I know "but mah monetization" is huge on this forum but it's not an all encompassing rule and it does not completely reflect the existing reality.

Strong disagree on this stance. You want to use the software? Cool, pay for it. Need access to source? It's on github, go nuts. Want to change it? Sure, feel free, but whoever uses it should pay the original developer. You can even charge extra for your modifications. Don't like the terms? Too bad - feel free to rewrite from scratch. FOSS simply isn't sustainable if you want to make a living out of it. It protects a…

Who are we to dictate terms to or divine the intentions of someone who releases software with say the MIT license? It might sound surprising but a lot of developers just want to share their work altruistically. There are some you couldn't pay if you wanted to. It's all voluntary.

> FOSS simply isn't sustainable if you want to make a living out of it.

This is probably true enough. Yet there are a million open source projects that existed, some for decades. There has go to be another way and another motivation.

> even those that don't actually matter to users that much - at the expense of the rights of developers

I would assume those developers would use a different license or even create their own terms.

> The only ones benefitting from the current situation are BigTech.

Paying the original developers will not change this. Big tech is big. They take whatever they can, sometimes killing the original project in the process. Perhaps a license like GPL is the solution to that particular problem.

I don't mean to come off snarky. I do agree with a lot of the things that you're saying but I see the free software movement as a completely voluntary and human thing. You could not get rid of it if you wanted. Paying for it is an auxiliary thing and concentrates too much on the wrong thing IMO. A lot of free software developers are already gainfully employed, some are millionaires. Yes some are struggling but then they are still voluntarily sharing their work with the whole world. That must mean they have their valid reasons for doing so.

Re: LittleSnitch for Linux

#385

Post by jshier »

littlesnitch wrote: post #261
jshier wrote: post #43

Earlier quoted context omitted.

Doesn't seem to be, I can see LittleSnitch itself connecting to yoyo.org and obdev.at. GP may be referencing a past bug, either in LittleSnitch or macOS.

If it connects to yoyo.org, you have subscribed to Peter Lowe's blocklist and Little Snitch is trying to update the list from there.

I have, yes. Didn't bother to check the domains, just wanted to say they were visible.

Re: LittleSnitch for Linux

#386

Post by patrakov »

littlesnitch wrote: post #244
sgc wrote: post #84

Earlier quoted context omitted.

I just tried littlesnitch and it did not resolve very many ips to domains, which is pretty basic. It also failed to identify most processes, and they were grouped under "Not Identified". It appears these are known limitations of the Linux version [1]. So for that alone I need to stick with opensnitch. [1] "Little Snitch for Linux is built for privacy, not security, and that distinction matters. The macOS version can…

Regarding unidentified processes: Little Snitch daemon must have been running when the process started in order to identify it reliably. It's best to reboot after installation so that Little Snitch starts before everything else. I should probably note this somewhere. And regarding failed reverse DNS names: Little Snitch is sniffing DNS lookups. If lookups are encrypted, there is little it can do. We usually recommend…

The thing is, 127.0.0.53 is a fallback. The real default upstream is nss_resolve, which talks to systemd-resolved via non-DNS protocol on a UNIX-domain socket. Ubuntu disabled this in favor of the less-featured fallback. If you insist on sniffing DNS, you need to add instructions to disable the native nss_resolve module by not including it in /etc/nsswitch.conf.

Re: LittleSnitch for Linux

#388

Post by mavhc »

delusional wrote: post #380
lilOnion wrote: post #235

Earlier quoted context omitted.

2026 is the year of the linux phone. We need to embrace that the year of the linux desktop (2025) was successful.

What does "the year of the Linux phone" mean when half the phones already run Linux?

And the other half run BSD

Re: LittleSnitch for Linux

#389

Post by hubabuba44 »

littlesnitch wrote: post #252
parhamn wrote: post #64

Okay hear me out, I use little snitch for a while. Great product. Love finding out what phones where. I make every single request (except my browser, because I'm fine with their sandbox) block until I approve. Recently I was wondering how you really have to trust something like little snitch given its a full kernel extension effectively able to MITM your whole network stack. So I went digging (and asked some agents t…

Disclaimer: I'm the developer of Little Snitch for Linux. Regarding MITM concerns: The eBPF component, which actually sees all the traffic, is Open Source (GPLv2). You can review it on Github and verify whether it sends any data to user space: https://github.com/obdev/littlesnitch-linux But the trust issue is still real, the daemon has to run as root because it needs to watch for new mounts and keep a table of file s…

I'm happy to see this on Linux and I really appreciate the open-sourcing of the eBPF component.

I maintain rustnet, a passive network monitor in the same eBPF + libpcap space, so I ran into a lot of the same issues. Wanted to share what has been working for me on the privilege side, in case any of it is useful for v2.

rustnet ships with setcap 'cap_net_raw,cap_bpf,cap_perfmon+eip' instead of setuid-root. During startup it loads the eBPF programs, opens the pcap handle, and then drops all three caps before touching any packet data. It clears the ambient set, sets PR_SET_NO_NEW_PRIVS, and applies a Landlock ruleset that restricts the filesystem to /proc plus configured log paths and blocks TCP bind/connect on 6.4+ kernels. Code is in src/network/platform/linux/sandbox/ if you want to have a look.

On the "needs to watch mounts" point, totally fair that Little Snitch needs live mount visibility, but I think it is achievable without staying UID 0:

- Watching for mount changes: poll() on /proc/self/mountinfo with POLLPRI wakes on every mount table change from a completely unprivileged process (this is what systemd and mount(8) use internally). Alternatively, an eBPF program on the mount/umount/move_mount tracepoints can be loaded at init and stream events via a ring buffer, with no continued cap cost after load. - Resolving an arbitrary PID to its binary across container mount namespaces: CAP_SYS_PTRACE is enough for that. The /proc/PID/root magic symlink does the namespace translation inline inside the kernel pathwalk, so open("/proc/12345/root/usr/bin/firefox", ...) opens the right file in the right container's view without ever calling setns(), which is what would otherwise need CAP_SYS_ADMIN (the new root).

Post reply on HN