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

[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.).

[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..

[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.

[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)

[starshipeleven]

Right now IBM-Redhat's "systemd" software

systemd predates the IBM aquisition by a long shot.

(systemd) is becoming a major player in moving Linux heavily into desktop space, a space the Linux has tried hard to grow.

Umm, no. Linux isn't "moving heavily in the desktop space" by any stretch of the imagination.

I can see IBM wanting to integrate/absorb "firewalld" into the "systemd" universe. IBM might even drive more Redhat products to "integrate" into a common package & "feel".

You need to understand that bikeshedding daemons between their own internal development teams is irrelevant in the grand scheme of things.
Firewalld is already as integrated as it can be, the whole point of it being connected to D-bus is to allow a system management application to give orders to the firewall.

Firewalld is just as NetworkManager and GNOME and systemd a part of the RHEL overall product/service.

The entire "systemd" software universe is a combined backend & frontend to various Linux internals that used to be handled by multiple programs.The "systemd" development approach is little more than the Micro$shaft approach done with Linux; "revise, extend, take over".

1. It was called "embrace, extend, extinguish"
2. You can't claim any of this can happen with a project that is 100% opensource, as any attempt to "estinguish" would result in a hard fork

On servers I prefer much more granular control with lots of little programs doing very specific tasks,

Somehow implying systemd project isn't using daemons for different tasks.

Ultimately, IBM could "roll" Redhat software packages into a major unified desktop release that is both easy for the end-user to use while being completely controllable from a centralized management system.

Are you aware of the existance of RHEL, (and SLES for that matter)? That's exactly what that is.

Such a product suite would make IBM competitive with Micro$haft again in the enterprise, and that's were the big money is.

I won't say RHEL isn't competitive in the enterprise (server) market, but it takes more than even a superior product to Windows to displace Windows.
It needs to be fully compatible with Windows applications too or there is no deal.

So what happens to Redhat if IBM does to them what IBM did to Lotus? What happens to the "systemd" universe and other projects created and/or developed at IBM-Redhat if the key programmers & developers start to leave because IBM starts to stamp it's "process & culture" on Redhat?

That the community or even the same programmers that get themselves hired by other companies make a hard fork and keep working at the same software.

This has happened with Openoffice vs Libreoffice, and with ZFS, and with Cinnamon and MATE (vs GNOME) and it worked well so far.

To IBM bigshots, it's all about making money for their investors.

Yeah, because RedHat and SUSE aren't also companies that need to turn a profit too.

Really, you are making a complete bs comparison with a closed source application, pulling in systemd for no good reason, and ignoring the existence of RHEL. Are you even serious?

[NotMine999]

firewalld is from Red Hat, it's not a piece of software some guy/girl is writing in his spare time.

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

IBM will polish it up, make it look all nice and shiny. IBM may even revise and extend it, add those IBM-specific details. Think back to Lotus 1-2-3. That company would bring out Lotus Notes. Then Lotus Symphony. Or IBM OS/2?

IBM acquired Lotus. Then they started polishing up the software and heavily marketing it to their customers. After all, who ever got fired buying IBM products?

Then IBM started to stamp it's influence on the Lotus operation. Knowledgeable Lotus programmers and developers within the organization would start to leave because of it. Then anyone that knew anything about Lotus software started to leave. Ultimately the "polished pile" would dry up and blow away in the wind. Where are Lotus products now?

Right now IBM-Redhat's "systemd" software (Lennart works for Redhat, right?) is becoming a major player in moving Linux heavily into desktop space, a space the Linux has tried hard to grow. I can see IBM wanting to integrate/absorb "firewalld" into the "systemd" universe. IBM might even drive more Redhat products to "integrate" into a common package & "feel".

Why?

The entire "systemd" software universe is a combined backend & frontend to various Linux internals that used to be handled by multiple programs. The "systemd" development approach is little more than the Micro$shaft approach done with Linux; "revise, extend, take over". I think that approach is necessary on the desktop because not every Linux desktop user will be a computing genius; stuff has to be kept simple, consolidated, & controlled. On servers I prefer much more granular control with lots of little programs doing very specific tasks, but now I am digressing to a different topic. Ultimately, IBM could "roll" Redhat software packages into a major unified desktop release that is both easy for the end-user to use while being completely controllable from a centralized management system. If you know M$ Windows Desktop & Server products, then you know what I am talking about. Such a product suite would make IBM competitive with Micro$haft again in the enterprise, and that's were the big money is.

So what happens to Redhat if IBM does to them what IBM did to Lotus? What happens to the "systemd" universe and other projects created and/or developed at IBM-Redhat if the key programmers & developers start to leave because IBM starts to stamp it's "process & culture" on Redhat? If you think it won't happen to Redhat, then you don't understand IBM management like I do, and you are foolishly trusting the press releases from the merger. To IBM bigshots, it's all about making money for their investors. Nothing more. If it doesn't make money for IBM by being a product their sales teams can push on their customer base, then it's product lifespan can be measured in minutes.

After all... it's only business.

[Nth_man]

So many years have passed, so many firewall systems on linux, but still you can't make rules based on which program initiates a connection (or accepts one). You know, exactly how most Windows firewalls work.
I know we're on linux with open source programs, but why trust them to connect to the Internet if they don't need it?

Years ago, I saw a program in Windows that, although the firewall "would not let it connect to internet", it launched Internet Explorer with a particular URL, effectively sending data...

[starshipeleven]

I can do that just fine with Gufw.

Afaik that's a "lie". In the sense that the "application" field is just for user convenience. It's not actually used to do anything more than show the user what that rule was for.

Linux kernel firewall infrastructure (iptables or nftables), which are the backend of ufw and gufw, have no concept of "application".

[starshipeleven]

So many years have passed, so many firewall systems on linux, but still you can't make rules based on which program initiates a connection (or accepts one).

This is not something a firewall alone can (or should be able to) do. It requires process tracking, and this can only happen at the system level.

I know we're on linux with open source programs, but why trust them to connect to the Internet if they don't need it?

You should look at firejail

while it's using a blacklist model (you need a profile for each application you want to provide limits for), it's able to block more or less anything.

firejail --net=none firefox

should start firefox with no network access, for example

(there is a tool that installs all profiles so you don't need to hack commandline arguments on your own.

[Vistaus]

So many years have passed, so many firewall systems on linux, but still you can't make rules based on which program initiates a connection (or accepts one). You know, exactly how most Windows firewalls work.
I know we're on linux with open source programs, but why trust them to connect to the Internet if they don't need it?

I can do that just fine with Gufw.