My biggest problem with Linux is that there are no per-process firewall settings. I think one can get around this by using AppArmor or using an user per app and assigning rules to a user.
I've used Linux for over a decade now, but there are still many things I haven't learned, so maybe I'm missing something in this regard.
The GitHub page says
- TCP network access control (binding and connecting)
and
- Support for UDP and other network protocol restrictions (when supported by Linux kernel)
so maybe this can be used to firewall processes in an easy way (assuming that it is easy to set up landrun)?
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`
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.
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.
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
You can use firejail for network isolation, it can run applications in a new network namespace [1]. I'm using this to run applications over tor to make sure that nothing leaks.
I saw there's an option to match on a cgroup among nft meta expressions (but I've never tried it). It could be enough if you just want to add per-process firewall rules, but not configure an additional namespace with it's associated interfaces, routing/nating.
Yes. You could match packets based on username or even SELinux labels.
You could also set a special mark on a packet for each container and then filter based on that. The Internet is surprsingly very thin on nft resources. I spent a few weeks learning how to write them. Definitely, not for the average consumer.
Attaching a separate firewall rules to every process would be a bit heavyweight. What we do have is network namespaces that let you have networking rules (incl firewall) per a group of processes.
that's what all firewall apps on Android (bastardized Linux) does.
well, they already have a user namespace per app which they can match on the firewall rule, but a per "main" program pid net namespace would be pretty much the same. i guess this can be a cool patch to this plus a one weekend qt+rust gui to manage the firewall (or a patch to firewalld gui)... only if i ever had a weekend.
I've used Linux for over a decade now, but there are still many things I haven't learned, so maybe I'm missing something in this regard.
The GitHub page says
- TCP network access control (binding and connecting)
and
- Support for UDP and other network protocol restrictions (when supported by Linux kernel)
so maybe this can be used to firewall processes in an easy way (assuming that it is easy to set up landrun)?