Debian 11 To Further Deprecate IPTables In Favor Of Nftables Plus Promoting Firewalld

[SledgeHammer_999]

Lolwut? `--pid-owner` ?!?

You do know that the pid of a program changes each time its launched right?

Capabilities-oriented security systems like SELinux and AppArmor are yet a different strategy to achieve the same too.

I have researched them, but on that front (network blocking) docs is limited and I think in one of them (maybe AppArmor) the capabilities were being worked on (ie no full features)

[jo-erlend]

What I worry with IBM-Redhat is that they will do to their version of Linux what they did to IBM-Lotus.

blablabla

Yes, the only real solution is to panic now in case there's a problem later.

[tuxd3v]

With iptables I cant filter out packets matching one of two subnets for example, nftables has way less restrictions.
The real improvements are largely internal, nftables rules can be easiser added and removed in a modular fashion, which is relevant if apps manage their own rules without messing up others. At work I cant use virt-manager and docker at the same time as their iptable-based bridging interfere with my network configuration.

Syntax is the least important issue, as the automatic iptables->nftables converters prove.

An advantage of Nftables, is that you can easily create your own tables, only the ones you use, instead of having some around and not been used..
Another advantage is the 'list' functionality which gives you a 'pretty-print' view of tables, chains, rules..
iptables rules are printed in a "crude" mode, which are more difficult to follow, visually..

But all in all maybe I still prefer iptables, nevertheless Nftables seems an interesting approach, I hope it will not be a disruptive one..

[DrYak]

You do know that the pid of a program changes each time its launched right?

Yes, and ?...

You pretended there's no way on linux to block peculiar programs from the network, I just showed you three different approaches.
( PID-based rules, AppArmor/SELinux, or the container-level in the case of container-based solutions).

I have researched them, but on that front (network blocking) docs is limited

AppArmor, straight from the man page:

Network Rules
AppArmor supports simple coarse grained network mediation. The network rule restrict all socket(2) based operations. The mediation done is a course grained check on whether a socket of a given type and family can be created, read, or written. There is no mediation based of port number or protocol beyond tcp, udp, and raw. Network
netlink(7) rules may only specify type 'dgram' and 'raw'.

AppArmor network rules are accumulated so that the granted network permissions are the union of all the listed network rule permissions.

AppArmor network rules are broad and general and become more restrictive as further information is specified.

eg.

network, #allow access to all networking
network tcp, #allow access to tcp
network inet tcp, #allow access to tcp only for inet4 addresses
network inet6 tcp, #allow access to tcp only for inet6 addresses
network netlink raw, #allow access to AF_NETLINK SOCK_RAW

Which means in your case (blocking network access on some piece of software) "deny network" should to the trick.

SELinux:
I'm not a SELinux guy, but a quick googling reveals that the current preferred method in SELinux is labelling.
(i.e.: iptable rules can SECMARK to attach a label to a packet, and SELinux rules can be used to control the access for these packets.).