Connection Alert / Notification pop ups?

[hubbaredneck]

Am I right in that the linux version does not yet support Connection Alert / Notification pop ups?

I was hoping to replace opensnitch as the UI for that is awful, but I do require Connection Alert / Notification pop ups for new/unknown connections.

[starkjohann]

Connection alerts are not possible with the type of eBPF interception we make in Little Snitch for Linux. Thats way more complex because the process must be paused or the network package must be put on hold while the alert is shown. I recommend OpenSnitch for this purpose.

I think it should even possible to run both, but have not tried yet.

I, personally, prefer the alert-less mode on new platforms because:

• As a developer of the Snitch, there is enough traffic that bypasses the filter while I debug, update, have buggy versions etc.
• I hate to be interrupted by alerts when concentrating. By using the monitor, I can decide when to take the time for making rules.
• After a while, you get an overview what's actually used and you can make better, more general rules. With alerts, you often make a rule for one host in a domain, then another, another and finally for the entire domain. Then you should remove the host rules.

[sean-at-git]

I think the issue here might be one of aspirations.

Little Snitch (for Mac) is such a fantastic tool with such rich and dependable functionality that the name carries with it a lot of expectations. When people read "Little Snitch for Linux", there is a lot of excitement for what such a polished product could look like with that name, but also a lot of expectations for things to work similarly.

In this case, it seems as though what is being offered (a very cool tool for monitoring, post-processing, and lookup-based blocking) is different enough from its namesake that some folks are disappointed it isn't everything they had hoped it would be. While it would be kind of silly to expect the 1.0 of a product launched on a new OS to be bug free and full featured, I think the disappointment expressed above is actually due to the expressed direction of the product.

It could be that "Little Snitch for Linux" is hesitant to push into OpenSnitch's market. Much more likely, however, is that all the complexity that has had to go into OpenSnitch over the last 6 years to make it function as well as it does highlights how complicated the scope really is. Making a product with anything even close to feature parity to Little Snitch for Mac would likely take substantially more work and investment than a free / partially OSS project is able to take on. Especially as a side project for a small company that isn't expecting to make any money on it.

[starkjohann]

Little Snitch for Linux is somewhere between Little Snitch Mini and Little Snitch. The name is already rather long and using "Little Snitch Mini for Linux" would even be longer. And it has features from the "big" Snitch as well, e.g. allowing rules by port and protocol. Just to explain the naming.

The design goal was to get the most functionality possible with the least complexity. With all the experience from past years we know (or at least believe to know) what can be done easily and what not.

For the original Little Snitch back in 2002, it was easy to show alerts. We intercepted system calls directly in the syscall table and it's always possible to put the thread to sleep at this point, show and alert and wake it when we have the response. Syscalls usually don't have timeouts. The app may set up a timer, but that's rare.

Apple changed things in the kernel. First they urged us not to intercept system calls, but rather use a new kernel API they made for exactly this purpose. This API was just a view call levels after the syscall, so it was still possible to pause the thread there. All was good.

Later, when the Network Extension framework was introduced, we already had a well established product and the framework was made specifically to allow pausing the thread and showing alerts. It was a tough job for Apple and caused tons of bugs.

Going to Linux, I looked at the available options for interception:

Having a loadable kernel module, we could do more or less the same thing as in Little Snitch 1: intercept the system calls. But two things: (a) there is very likely a reasons why this is strongly discouraged, and (b) a kernel module must be recompiled for the particular kernel of each machine. The installation procedure would have to compile the source code and users would have to install the compiler. Not cool, particularly if the compile fails.

Intercepting with iptables/nftables is possible, but we would redirect traffic (at least temporarily) to a daemon. That means crossing the userspace/kernel barrier two more times, which costs performance. Pausing a connection (discarding the handshake packet and re-injecting it later) would not pause TCP timeouts, so the user would have to respond fast. That's hard to explain. And I personally don't like processes like Docker which change my carefully crafted iptables setup.

eBPF looked exciting. I had already worked with BPF on the Mac. In late 2020, Apple decided to whitelist "important" connections from firewalls like Little Snitch. We had to come up with a reaction, so we added a second interception at the network interface level using BPF. This second interception gave us enough info to tell which connections bypassed our filter.

I decided to use eBPF, because the technology is really cool. However, eBPF is very restrictive in what you may do. You cannot put the thread to sleep. And at the interception points where process information is available (which we need for rules and statistics), network packets cannot be held back. And even if it were possible to hold them back, it would not be possible to re-inject them at will (because there is no call from user space to eBPF). And even if this were possible, we would still suffer the same problem as with iptables/nftables: TCP timeouts would not be paused and the user would have to respond fast.

So in summary: With the given technology, an alert mode is really hard to implement. What we could implement: show a notification of some kind when new connections occur which are not yet covered by a rule. That would help for default allow and deny configurations.

[taoeffect]

What are your thoughts about doing it the way OpenSnitch does it via netfilter/NFQUEUE?

You could fork their codebase and just improve the UI, couldn't you? (Or maybe even team up with them?)

FYI: https://deepwiki.com/search/what-method-does-opensnitch-us_23a38c64-09e9-401d-bde7-a6c1aec58a30?mode=fast

Details

[taoeffect]

Oh, apologies, I think that's somewhat related to your comment regarding iptables/nftables?

Intercepting with iptables/nftables is possible, but we would redirect traffic (at least temporarily) to a daemon. That means crossing the userspace/kernel barrier two more times, which costs performance. Pausing a connection (discarding the handshake packet and re-injecting it later) would not pause TCP timeouts, so the user would have to respond fast. That's hard to explain. And I personally don't like processes like Docker which change my carefully crafted iptables setup.

[starkjohann]

Yes, that would be a possibility. But I think it would be easier to enhance the UI of OpenSnitch than to merge this part of the functionality into LS for Linux.

For me, personally, it's not worth the effort. After 24 years of using Little Snitch on the Mac I try not to deny too much. It tends to break things. I watch the apps closely and if something misbehaves and can't be changed in the settings, I just remove the app and use something else. There are exceptions, of course: I can't replace Xcode and macOS, so I have rules for these. And I have a default deny rule for my mailer and allow mail servers explicitly. And a default deny rule for the password manager, just in case.

For me, it would be more relevant to see (via notification) when the default deny rule for my mailer or password manager gets used because that should never happen. And to analyze it retroactively, whether it was used within the last weeks or months.

[sean-at-git]

If they were to add in connection alert style actions, I imagine it would need to be asynchronous to align with the current design goals (remote execution and web-based monitoring, for instance). To accomplish that, perhaps leveraging the deny-by-default mode, but having it generate something like a "user action" queue that can be reviewed and actioned later (either in the web UI, or some future native UI with popups). All the content that would normally go into a connection alert on Little Snitch for Mac could be stored in each queue element for future action.

This could potentially go a long way to bridging the gap between current after-action monitoring and the Mac version's popups, and shouldn't be too invasive to the current implementation. That is assuming it could be implemented by appending a "pending user action" to a queue when the default deny rule gets hit.