Live data from Hacker News

LittleSnitch for Linux

obdev.at

321–330 of 489 posts

Re: LittleSnitch for Linux

#321

Does little snitch and similar software work against solutions like Paqet? https://github.com/hanselime/paqet

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.

Re: LittleSnitch for Linux

#322
post #217

Earlier quoted context omitted.

What else is this about? Debian repositories still contain no malware and if you install software exclusively from them, you'll be safe.

Run OpenSnitch for a while and you'll quickly realize how much of your system does phone home. Off the top of my head: - GNOME Shell (extension updates without a way to disable this, weather), - GNOME Calculator (currency exchange rates), - NetworkManager (periodic hotspot portal checks in most configurations), - GDB (debuginfod enabled by default), - Firefox (extension updates, push notifications, feature flags, tel…

you could always run kwin_wayland and prevent all that phoning home...

Re: LittleSnitch for Linux

#323
LittleSnitch for Mac is a good looking app.

I always thought that ugly UIs on Linux are because of good designers do not intersect well with programming enthusiasts.

But looking how ugly same app looks on Linux, I’m starting to think it could be a technical limitation. Can someone elaborate?

Re: LittleSnitch for Linux

#324

cool to see eBPF used for a desktop firewall instead of just ddos packet dropping. the note about bpf map overflows is super relatable, dealing with that on bare-metal is a pain. my question is... if the tracking maps fill up completely, does the daemon fail-open or fail-closed?

There is currently no treatment of errors because I would not know how to handle them anyway. There are two tables which can overflow affecting the filter: the table of open flows and the table of recent DNS lookups. The table of flows just fills up, meaning that we cannot store state about new flows. Without state, we can't attribute a process to them and end up evaluating rules on each packet. I guess that blocklists would still work, but more specific rules would not be applied (and the default decision would be taken, whatever you have configured).

The DNS lookups, on the other hand, are LRU. If the table overflows too soon, we won't be able to derive names for IP addresses and name-based rules would fail.

Re: LittleSnitch for Linux

#325

LittleSnitch for Mac is a good looking app. I always thought that ugly UIs on Linux are because of good designers do not intersect well with programming enthusiasts. But looking how ugly same app looks on Linux, I’m starting to think it could be a technical limitation. Can someone elaborate?

It just depends on the UI frameworks available to developers and their interest in building something good-looking. Different UI frameworks are available for different platforms, and there are only a few good ones that are cross-platform. Qt and GTK are pretty common for linux apps and typically don't look great.

Re: LittleSnitch for Linux

#326

I used Little Snitch on Mac a few years ago and liked it, though I wasn't a fan of how (necessarily) deep it had to be in the OS to work. It felt like one of those things where, the moment you have any kind of network connectivity issue, it's the first thing you need to disable to troubleshoot because it's the weirdest thing you're doing. I guess what I'd really like is a middleware box or something that I could put…

I’ve also wanted something like this. The challenge is with an external appliance you lose awareness of which process is initiating the request.

This is solvable to some degree but requires varying degrees of new complexity depending how smooth of a user experience you’re aiming for.

Re: LittleSnitch for Linux

#327
post #231

Earlier quoted context omitted.

The year of the Linux Desktop will always be $CURRENT_YEAR + 1

What do you call a fallacy where it is implied that the future will be like the past?

Reminds me about schools of thought on rates of change:

  > ## Accelerating Change [One School]
  >
  > Our intuitions about change are linear; we expect roughly
  > as much change as has occurred in the past over our own
  > lifetimes. But technological change feeds on itself, and
  > therefore accelerates. Change today is faster than it was
  > 500 years ago, which in turn is faster than it was 5000
  > years ago. Our recent past is not a reliable guide to how
  > much change we should expect in the future.
  >
  > Strong claim: Technological change follows smooth curves, 
  > typically exponential. Therefore we can predict with fair
  > precision when new technologies will arrive, and when they
  > will cross key thresholds, like the creation of [AI].
  >
  > Advocates: Ray Kurzweil, Alvin Toffler(?), John Smart

  https://www.yudkowsky.net/singularity/schools

Re: LittleSnitch for Linux

#328
post #312
post #281

Earlier quoted context omitted.

> surely you know how often it happens that developers of popular extensions are approached by shady businesses and sometimes do even sell. Yes, developers of free extensions who sell for a pittance. I don't have a popular extension. My extension is relatively expensive and thus unpopular. I don't have enough users to be interesting to shady businesses. My extension is more valuable to me than to anyone else, because…

> My extension is more valuable to me than to anyone else, because I, one person, can make a living from it. I believe you, and as a fellow indie developer trust you and your intentions and that you’re careful to not be compromised. But if I’m being honest with myself I don’t have concrete proof of any of those. So I trust but also try to limit the blast radius if anything goes wrong. Does that make sense? I think yo…

> I don’t mean it in the sense of software dependencies, but in the sense that some app you use would compromise you. You know macOS’ permissions are mostly security theatre. We know people inside Apple use third-party apps. I can imagine ways of exploiting that, given a bit more knowledge of people from inside (which could be gathered from working there for a while, trawling social media, maybe reading Gruber’s emails, …).

You seem to be waffling here between targeted and untargeted attacks.

There's a world of difference between compromising me or an Apple employee and compromising my software or Apple's software. You don't magically get the latter from the former.

Untargeted attacks are just looking for the usual stuff, e.g., money. They don't care about who the victims are or what else they have.

It would require a targeted attack to insert mallicious code into my software or into Apple's software. You claim, "I can imagine ways of exploiting that," but I don't actually believe you. If you can imagine it, then explain exactly how.

There's no evidence that anyone is targeting my software or that anyone has any reason to target my software. Even if I downloaded a typical malware app from the web, that wouldn't result in malicious code getting shipped in my software.

I'm not aware of anyone on the Apple Passwords team using my software, so if someone were trying to attack me to get to them, that's seems a bit fruitless, to use a pun. In any case, the chain from compromising me, to compromising my software releases, to compromising an Apple engineer, to compromising Apple software releases, is convoluted to the extreme and would require much more specifics than anyone has given here (or is capable of giving).

In any case, I'm quite careful—though not tin foil hat paranoid—about which software I download and run on my Mac, and I've never downloaded malware in more than 20 years as a Mac user. Obviously I'm careful about my own privacy and security, since I use Little Snitch too!

Re: LittleSnitch for Linux

#329
post #167

I know it sounds crazy at this point, but with popular YouTubers switching to Linux, gamers overall well-aware of Steam on Linux advantages and switching as well, plus popular software like LittleSnitch getting ported, 2026 can without irony be named as Year of Linux Desktop, right?

does wifi work yet? last year it didnt for me

WiFi works fine if there are drivers for whatever WiFi chip you have.

Unfortunately there are no standards for OS to talk to WiFi devices like exist for many other types of hardware, so it’s not possible to make generic drivers.

Re: LittleSnitch for Linux

#330
post #181

Earlier quoted context omitted.

It's interesting hw lng it took for linux to get a user friendly application firewall like OpenSnitch

It's because there's no way to make universal kernel modules/drivers, like it is on Windows.

The way to make kernel modules is to submit them to the kernel. Not really sure what a “universal kernel module” really is.

Also that seems irrelevant because it seems this was implemented in eBPF so no kernel modules are required.

Post reply on HN