An ingress packet doesn’t come with a process ID.
How can the wanted functionality not be implemented by applying filters to the port bound by the process?
Perfect for alerting while under the Default-Deny Firewall.
Somehow, FreeBSD has those.
Example Rule: allow process "squid" with shasum "1a2b3d4" running as user "squidy" to receive packets via "TCP" port "3138"
> How can the wanted functionality not be implemented by applying filters to the port bound by the process?
A port filter is dumb in a sense, anything can be underneath. It's fine for something like a web server, run by root, on a couple of consistent ports, running all the time. Process based rules might be more useful for services with dynamic port ranges or real people running random things.
Your questions concept may be the easiest way around the issue in Linux world. It could be easier to have BPF monitor process start/stop and port open/close changes and modify the allowed ingress to suit the process based ruleset than it is to attempt the lookup purely on the inbound path. Due to the multi process listening feature, the connection > process mapping info may only be available after it's happened which might not be the best point to firewall something.