I second OpenSnitch, I haven't face any shutdowns due to it yet. For those coming from LittleSnitch on macOS might have to look into the finer details of the connection in the Allow/Deny dialog on OS to get the best results.

Slowdowns, not shutdowns, luckily:) The desktop (XFCE under Debian if that helps) just hung for a while like it was waiting for me to allow some rules, but didn't show the requester to do so, also the timings were random, could have been from 2 seconds to 5 or more.

Oops; Self-reminder to not comment on HN when half sleep.

But, I haven't noticed slowdown either; I wonder whether its because I always keep the OS window open?

Keep in mind, OpenSnitch is Linux-based and none of Linux firewalls can filter incoming packets by process ID like macOS/FreeBSD (Lil'Snitch) can.

From what I understand opensnitch use ebpf to match where the exiting packets are going. TCP being TCP, it is easy to know where the incoming answer will be delivered to as well.

Not sure if this would work also for connectionless protocols such as UDP. That is, if I open a socket and send some datagrams to an external address:port to exfiltrate users data, then close the socket and exit, I don't think it would be able to tell which program did that, unless it detects it live.

I believe opensnitch catches them.

I think iptables was supposed to be able to do this, right?

https://linux.die.net/man/8/iptables

    --pid-owner processid
        Matches if the packet was created by a process with the given process id.

But was disappointed by the note:

> NOTE: pid, sid and command matching are broken on SMP

--pid-owner was removed from Linux some time in the 2.4 days IIRC.

That's a really outdated version of the man page. The current one is: https://ipset.netfilter.org/iptables-extensions.man.html

Probably the closest thing these days is to use the cgroup match extension, together with something that makes sure separate apps are moved to their own cgroup. But that cgroup would be under a separate parent cgroup for each user so it's not ideal.

I expect NFQUEUE or some EBPF magic is a better way to do things - you don't want to be constantly adding/removing per-process iptables rules.

Iptables is a little old. You may want the newer nftables instead.

The iptables rules can be converted directly to nft with iptables-translate and the syntax is more simple.

The owner module can control outbound communication by uid/gid. [1] There are no modules to handle things by PID AFAIK. This can however be accomplished by SELinux and Apparmor custom rules but that is a loaded topic.

Firejail [2] and Bubblewrap [3] can put limits on application capabilities and/or take away network access.

A round-about and heavy handed way to manage communications by PID would be to isolation applications in their own VM or container and map the VM or container to a unique user or group.

[1] - https://ipset.netfilter.org/iptables-extensions.man.html

[2] - https://github.com/netblue30/firejail

[3] - https://github.com/containers/bubblewrap

OoenSnitch can, but it's not implemented O:) (only as a PoC)

But does it have any sense? Usually you block inbound connections, allowing only certain services. If a rogue process starts listening on a local port, you could display a warning alert, and as inbound connections are already blocked you'd be safe (as long as you trust netfilter...) and you wouldn't need to ask the user to perform an action.

The slowdowns are because it still has to hold every connection until it can check which program it is coming from and whether that program is trusted or not, even when the same program creates multiple connections.

To get around the slowdowns, I made an alternative program called picosnitch which only monitors connections since I just stop using anything I don't trust or move it to a sandbox. It also uses BPF, has fairly low CPU usage, and some other features for improved reliability and detection of programs.