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!!
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?