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