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

451–460 of 489 posts

Re: LittleSnitch for Linux

#451

Post by littlesnitch »

thewanderer1983 wrote: post #432
littlesnitch wrote: post #321

Earlier quoted context omitted.

On macOS, it requires access to /dev/bpf . That's why we added filter rules for bpf there. On Linux, we intercept at a level where packets already have an Ethernet header. I hope that Paqet injects before* this layer, but only a test can give the proof.

Thanks for the response. Sorry I should of been less vague. Paqet works on raw sockets with KCP. Though it's intended for good. What's to assume bad actors aren't also using this method to get around solutions like littlesnitch? A recent example, but not the only is a Iran a botnet, using this to get around detection. https://cybersecuritynews.com/iran-linked-botnet-exposed-aft...

Little Snitch for Linux is not made to defend against malware. You need to code with paranoia in mind from the very beginning if you want that.

Re: LittleSnitch for Linux

#454

Post by littlesnitch »

cxr wrote: post #435
littlesnitch wrote: post #315

Earlier quoted context omitted.

As the author of Little Snitch for Linux, I can tell you what drives us: we are a small company where people (not investors) make the decisions. It was a personal choice of mine, driven by a gut feeling. I'm curious about the outcome...

The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that? Why is Little Snitch for Linux™ so hard to find from the company homepage[1] and the product page from the legacy app[2]…

I'll post in our blog about the development background later. The Linux version shares no code with the Mac version. Only concepts. It's written in Rust and JavaScript (for the Web UI).

Our site is primarily aimed at Mac users, and most visitors skim rather than read carefully. If the Linux package were more prominent, Mac users would likely click it, struggle to install it, and blame us for the confusion.

And regarding your third question: No. The decision was made when I wanted to run it on our headless servers.

Re: LittleSnitch for Linux

#455

Post by littlesnitch »

cxr wrote: post #436
cxr wrote: post #435

Earlier quoted context omitted.

The Wikipedia page for Little Snitch indicates that it's written in Objective-C. Is that still the case? Before going with the new implementation, did you attempt (or consider) to port the current codebase (using e.g. Cocotron or GNUStep libraries)? If so, how good or bad of an experience was that? Why is Little Snitch for Linux™ so hard to find from the company homepage[1] and the product page from the legacy app[2]…

Intentionally not edited to add: Why are you using minified dependencies (like uPlot.iife.min.js[1] and uPlot.min.css[2]) for a desktop application? uPlot is also open source (released by Sorokin under MIT), but why aren't you following the terms of its license[3]? 1. https://github.com/obdev/littlesnitch-linux/blob/main/webroo... > 2. https://github.com/obdev/littlesnitch-linux/blob/main/webroo... > 3. https://githu…

Sorry, I overlooked that. I actually checked the license only to the point whether we can include it without other obligations and then downloaded what was offered as a download on either the web site or github, can't remember. I decided for the minified version because it's smaller. That's the purpose of minification, after all.

It's somewhat strange that they require the license to be reproduced in every copy, but then offer a download without it. But anyway, I'll prepend the license to the next public release.

Thanks for pointing that out!

Re: LittleSnitch for Linux

#456

Post by littlesnitch »

jron wrote: post #342
littlesnitch wrote: post #315

Earlier quoted context omitted.

As the author of Little Snitch for Linux, I can tell you what drives us: we are a small company where people (not investors) make the decisions. It was a personal choice of mine, driven by a gut feeling. I'm curious about the outcome...

As a paying customer, I wasn't expecting this so thank you! Can you expand more on your gut feeling? Also, I have different security expectations on Linux vs MacOS. Would you ever consider open sourcing the daemon?

It's hard to expand on the gut feeling. I wanted to have the app myself. Adding licensing to the code, limiting functionality for a demo mode, and then wait whether Linux users would pay for it just did not feel right.

Regarding daemon open source: The future is hard to predict, even more with AI being just invented. I would love to make it open source, but if you can feed it into Claude and tell it to convert it to a Mac version, we could lose our income.

For the moment, we prefer to keep it closed because we cannot estimate the consequences of making it open source.

Re: LittleSnitch for Linux

#457

Post by littlesnitch »

hubabuba44 wrote: post #389
littlesnitch wrote: post #252

Earlier quoted context omitted.

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 start…

Thanks for sharing! I took rustnet as proof that complex eBPF programs can be done in Rust. Otherwise I would not have dared to try this!

Reducing the set of privileges is on my todo list, but for the moment I just want to get things working without worrying about self-made limitations.

Regarding mount points: I needed the inode numbers of the mounted nodes. With my last commit this requirement has been dropped and it should be sufficient to read mountinfo (and access config files and sqlite3 databases, of course).

I don't need to get the executable from PID, that's already done in eBPF because I need to apply rules based on executable paths.

Re: LittleSnitch for Linux

#458

Post by littlesnitch »

patrakov wrote: post #386
littlesnitch wrote: post #244

Earlier quoted context omitted.

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.

Thanks for that hint! We still get the lookup if it leaves the machine unencrypted, but if you have both, the Unix domain socket and DNS encryption, we miss lookups.

Re: LittleSnitch for Linux

#459

Post by littlesnitch »

janc_ wrote: post #348
littlesnitch wrote: post #244

Earlier quoted context omitted.

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…

Not all "hostname lookups" by applications happen over DNS (or the DNS is done by something like systemd-resolved, which is often using encrypted lookups), so in many cases, depending on NSS configuration (e.g. 'file', 'resolve', 'db', 'nis', 'mymachines', 'libvirt', 'winbind', ...) this would never work?

Yes. For these cases it won't work. OpenSnitch intercepts the client side library for this reason. I would rather want to avoid this for the moment and wait for feedback.

Re: LittleSnitch for Linux

#460

Post by littlesnitch »

sgc wrote: post #367
littlesnitch wrote: post #244

Earlier quoted context omitted.

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…

If I don't know who my machine is talking to, the information is not very useful. So there needs to be a fallback on some level. Perhaps there should be a mode where littlesnitch just does its own lookup using the system-configured rDNS, for example from the ui or for specific processes, etc? It should be cached if it is a recent lookup, so minimal performance implications; and offloaded to the system rDNS resolver,…

What exactly do you mean with rDNS resolver?

We do not want the reverse lookup name. For instance, if you look up a google.com name with dig, you get an IP address. If you then do the reverse lookup with dig -x, you get a 1e100.net name. That's as good as the IP address for our purpose.

Plus: We need to respond with a DROP or ALLOW verdict to a network packet without the ability to do any blocking requests. So we can only use information already available in the kernel to decide.

Post reply on HN