I wrote picosnitch [1] which has the same notification and bandwidth monitoring features, however it doesn't block traffic for a couple reasons: avoiding scope creep so I can focus on more reliable detection and do things like hash every executable, which makes it harder to block traffic in a timely fashion.
What is your threat model, and what type of traffic are you hoping to block?
I never claimed picosnitch to be a firewall. My use case involved running it on servers with a minimal OS where all applications are containerized. My goal was purely monitoring to see if any containers had rogue executables, and go from there.
Without the containers, it would be trivial for a malicious program to stop or modify picosnitch, and the same goes for firewalls hoping to block programs on Linux due to its security model [1]. You need to use some sort of sandboxing [2].
I never claimed you claimed it. I was just pointing out the huge deficiency that makes picosnitch not an alternative to the broader use case littlesnitch supports
To sidestep the more complicated discussion re. how poor the security architecture of Linux is, let's limit that use case to blocking legitimate apps' connections for privacy reasons
I apologize, that's a fair question given that I named it after Little Snitch. One reason I used the prefix pico is because it's extremely little, supporting only a subset of Little Snitch's features.
On Linux there's already a number of great apps for blocking legitimate apps' connections, however they all still support only a subset of Little Snitch's features, and there wasn't one that offered the subset I provided with picosnitch. Which of those features you consider most important is subjective and dependent on your use case. I consider picosnitch a valid alternative and the core feature to be snitching on programs, the same goes for the new free tier of Little Snitch Mini.
Also like I said above, it is difficult to hash executables and block them without introducing delays the first time anything connects to the internet. If you're only concerned about blocking legitimate apps' connections you don't need them to be hashed since you can trust them not to do anything too nefarious. Personally this was more useful to me, since if I see an unexpected new program or hash during updates, or a new hash outside of updating my containers, I can intervene or have another script stop my containers and alert me. I also get some value from this on my desktop since I do all my development inside containers, and use another drive with Windows solely for gaming.
I noticed this is pretty new and a couple things caught my attention
> the primary advantage is that it has direct access to the pid, executable, and commandline of the process making the request.
Does this mean it is guaranteed to be able to open a copy of the executable no matter how short lived it is? This was quite a challenge for me when trying to grab it in time for hashing. I ended up settling on simply opening /proc/pid/exe as early as possible, marking it with fanotify, then putting it in a queue to read later and reporting it if it was modified before being read.
> the systems fails closed. when snitch isn't running, network requests are not possible.
This is a pretty impressive feature which I haven't seen elsewhere. I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
> Does this mean it is guaranteed to be able to open a copy of the executable no matter how short lived it is? This was quite a challenge for me when trying to grab it in time for hashing. I ended up settling on simply opening /proc/pid/exe as early as possible, marking it with fanotify, then putting it in a queue to read later and reporting it if it was modified before being read.
no, it just means it knows the name and path as reported by the kernel at that time.
i originally had wanted to monitor the filesystem in addition to network, since lsm allows that. however the filesystem implementation was tricky, and i couldn’t find a good solution to the problem you described: verification by hash or some other means that the path being executed is a known trusted binary.
all mighty snitch knows is the path of the executable and the argv array as reported by the kernel at the time the lsm hook is called. it’s not the best, but it’s better than nothing.
> This is a pretty impressive feature which I haven't seen elsewhere. I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
i think failing closed is more inconvenient than difficult, which is why things often fail open. when using a mighty-snitch kernel, the network is inaccessible until you start the userspace process. better security might involve only allowing userspace to start once, or other such restrictions.
then again you also have to secure the filesystem, since that is where permanent rules are stored.
in reality, it depends on your threat model. i find network monitoring to be tremendously useful both for debugger and for more feeling secure. hopefully also for being more secure.
nfq, which tinysnitch uses, can also fail closed. then again you have to use iptables or nftables for that, which may in fact fail open.
> I'm not familiar enough with lsm to know what's possible and I see you use a custom kernel. What sort of guarantees does this provide and have you come across any limitations?
lsm is only usable with a custom kernel, which probably why most people don’t. basically it returns block unless it can talk to userspace, in which case it returns block or allow depending on which userspace chose.
as for limitations, currently we can’t reliably read the remote ip for inbound connections. it would be nice to have that information as well.
just looked up your username. picosnitch is cool! email me if you want to discuss further, and keep building cool things!!
> i originally had wanted to monitor the filesystem in addition to network, since lsm allows that. however the filesystem implementation was tricky, and i couldn’t find a good solution to the problem you described: verification by hash or some other means that the path being executed is a known trusted binary.
The most promising approach I've come across which may accomplish this is using fs-verity or bpf_ima_file_hash. However I haven't looked too much into it since I'm mostly working on other things now and my current approach works well enough. Also I have yet to take into consideration shared libraries and things like LD_PRELOAD rootkits.
> then again you also have to secure the filesystem, since that is where permanent rules are stored.
I've worried about this too, it's a little easier for a server if you minimize what you have on the host, bonus points if it's immutable, and run everything in containers. This is a little harder to do on a desktop without creating too much inconvenience though.
> in reality, it depends on your threat model. i find network monitoring to be tremendously useful both for debugger and for more feeling secure. hopefully also for being more secure.
Yep I agree, and it's also useful for learning about your system and networking, to help make better decisions when it comes to security.
> just looked up your username. picosnitch is cool! email me if you want to discuss further, and keep building cool things!!
