[QuantumNoodle]

Why not use linux network namespaces to run your processes in different network stack? nftables rules are per network namespaces so you can get all sorts of sophisticated and achieve essentially per process firewalling. The pattern is to create a network namespace, create a veth pair and move one end of the pair into the namespace. Then you could set up rules to route traffic from default namespace to the process namespace via veth device.

Systemd has `NetworkNamespacePath` directive which can spin up services in new namespaces as well. See `man 5 systemd.exec`

[mikedelfino]

I'm not sure about the other commenter's intentions, but on desktop, I wish every program started in a restricted network namespace. Instead of blocking all incoming and outgoing connections by default, it would request user permission interactively and adjust access accordingly.

[coppsilgold]

On Linux you can do the next best thing which is to move out all the interfaces from the default network namespace and use iptables rules for it which block everything just in case.

Then you have to explicitly launch applications in a desired network namespace such as physical (eth0, wlan0 etc) or vpn (wg0).

Accidentally launched applications, or something like the desktop environment have no network connectivity.

[ranger_danger]

opensnitch does this

[y7]

Are you sure? Because last I checked OpenSnitch used different techniques from namespaces, that seemed more brittle to me.

[ranger_danger]

I was referring to "request user permission interactively and adjust access accordingly"... it can do that. It uses eBPF though

[ranger_danger]

My biggest issue with using namespaces is that it bypasses the main host firewall entirely.

[QuantumNoodle]

That depends on how you set it up, it doesn't have to bypass the "main host" firewall. Consider the following example:

0. If you set up no additional network namespaces, there is still one present, this is called the "default" or "root" network namespace. It is what you refered to as "main host".

1. Say the default net ns has device eth0 that your server receives traffic on.

2. You create a veth pair in the default net ns, veth0 and veth1.

3. You create a new net ns and move veth1 into new net ns. Only veth0 and eth0 remain in default net ns.

4. You set up routes and nftable rules in default net ns as you would normally. Certain traffic you want to route to your new net is so you have a next hop veth0 (note, you ha e to route through to the IP of veth1, using veth0 as next hop)

5. You set up additional nftable rules and whatever you want in the new net ns and this is isolated from default net ns.

End-to-end flow: packet arrives on eth0, traverses netfilter (nftables/iptables) and route lookup to route to "new network" via veth0. Packet is sent "out" the default net stack via veth0 and arrives on veth1 (since they are a pair) in new net ns network stack. There, the packet traverses an isolated netfilter and routing table and a socket can be listening for your service or whatever. Replies would follow the same in reverse. Sent out veth1 in new net ns, arrive on veth0 in default net ns, and exit that stack via eth0

[ranger_danger]

I was speaking from a defensive security point of view and not a server trying to route traffic.

The fact that local users can simply create namespaces that bypass the host's firewall is extremely dangerous in my opinion.