Systemd 240 Released To End 2018 On A High Note

[doublez13]

I hope that in the future systemd will add a easy to use and understand firewall to their existing network code.

With RedHat being the developers of both Systemd and Firewalld, I don't see that happening. But maybe.

[rtfazeberdee]

I now know you do not understand what people say.

errr... what exactly are you referring to?

[Vistaus]

At the moment this is the situation. Do you like an "under heavy development" OS? Feel free to use it, I do not call you insane. I want a different solution, I am a simple "Linux user" (not a sysadmin), and I want to keep my data safe in the hard disks. That's all.

I'm also a simple "Linux user" (not a sysadmin, not even a developer, just a regular user) and systemd is fine for me. It was a bit atrocious in the past, but since the last couple of releases, it's fine and stable and I find it much, much easier than sysvinit.

[Laser]

I hope that in the future systemd will add a easy to use and understand firewall to their existing network code.
I remember that in one of theirs conference videos Lennart or some other developer said that they would want to add a firewall that is program based, not port based.

I think Lennart referred to this http://0pointer.net/blog/ip-accounti...h-systemd.html

[caligula]

What worries me is how systemd is adopting container tech. They're replacing the lean, lightweight, super optimized minimal docker with super bloated systemd-nspawn. Oh wait..

[NotMine999]

I hope that in the future systemd will add a easy to use and understand firewall to their existing network code.
I remember that in one of theirs conference videos Lennart or some other developer said that they would want to add a firewall that is program based, not port based.

"easy to use" and "firewall code" tend to conflict with each other. An "easy to use" firewall may be "not secure enough" and bad stuff can get through, or "too secure" and stuff breaks. There is never a program/coding design that satisfies every user's opinion on this topic.

That would be great for someone like me who doesn't want to search online which ports a program uses and then add a rule for those.

That is a nice idea but it becomes a maintenance problem for any developer/maintainer that is writing Linux code in their spare time or without a major corporation subsidizing/underwriting their work. Why is this?

You are assuming that applications use a specific port or range of ports all the time. That is true for applications on the "well known ports". Some applications use port numbers outside of that "well known" range. Nothing says that application developers always have to use the port(s) they were originally written to use if they are outside the "well known" range. Sometimes application developers change port numbers in future releases simply to get around firewall rules. In other words, never expect application code to behave in a future release like it did in a past release; good enterprise support teams have dedicated test teams to find those issues before they roll out a new OS or application version to their users.

The impact to firewall developers is having to keep pace with the work of application developers, both in code development, updating, and testing. There is no obvious notification process unless the firewall code maintainers subscribe to every email list out there; an unrealistic expectation for any developer when their teams mostly work independently of each other. So that means there will always be a lag between what application developers do and what the firewall developers/maintainers program. Any lag in support means "breakage". Do you want "breakage" where you will have to wait for a future update?

Your idea could appear as a "subscription" service where Linux users that want it can pay for it. That would help underwrite/subsidize the massive maintenance process, but it does nothing to fix "the lag" between work done by application developers and firewall code updates. Would you be willing to pay for such a service even though there may still be a "lag" and occasional "breakage"?

Besides, I think the program could just dynamically use another port or change the used port after an update and then the firewall rule would have no effect and the program could still use the network as if it were no firewall.

Good idea, and iptables/netfilter should support that type of update. I use "shorewall" and it does support this concept right now. Keep in mind that such an update command has to be issued with "root" privileges since iptables/netfilter run with "root" privileges. You should also want a way to test the changes and revert to the previous version; that means 2 types of updates have to be supported/programmed. So you have to deal with "sudo" or UAC popup boxes ("Windows" term) if your Linux user account does not have "root" privileges. Some users find that "privilege escalation by entering a password" stuff annoying on Windows and always operate with a Windows user account that has "administrator" access (a very bad idea).

Something like this already exists on Android if you install AFWall+

https://f-droid.org/en/packages/dev.ukanth.ufirewall/

I hope to see something smart and easy like that built-in Linux too.
Maybe then distros can add a firewall section to their respective control panels.

I honestly think that "something smart and easy" will have issues with the internal code security model/structure of the Linux OS. Windows permits users to do "something easy" at the expense of being "smart". I really don't want to see that model migrate to Linux.

[re:fi.64]

Guest Do you mind sharing a bit more about the problem?

[starshipeleven]

I hope that in the future systemd will add a easy to use and understand firewall to their existing network code.
I remember that in one of theirs conference videos Lennart or some other developer said that they would want to add a firewall that is program based, not port based.

That would be great for someone like me who doesn't want to search online which ports a program uses and then add a rule for those.
Besides, I think the program could just dynamically use another port or change the used port after an update and then the firewall rule would have no effect and the program could still use the network as if it were no firewall.
Something like this already exists on Android if you install AFWall+

https://f-droid.org/en/packages/dev.ukanth.ufirewall/

I hope to see something smart and easy like that built-in Linux too.
Maybe then distros can add a firewall section to their respective control panels.

If they add that you would have to edit systemd service files of that application, and start it through systemd somehow, as it would be a sandboxing-like thing (just as it is for Android), not a firewall in the proper sense of the word.

Firewalls that actually inspect traffic and block applications regardless of ports and IPs are called "application firewall" but require significant amounts of resources as they are inspecting all packets and keeping track of what is going on.

Currently the most similar thing is "portals" feature of flatpack where you can give flatpacked applications that are otherwise sandboxed permission to access something when they ask for it (similar to Android), but it's still under development.

[starshipeleven]

I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.

Something else failed and systemd is just what you decided to blame.

[starshipeleven]

"easy to use" and "firewall code" tend to conflict with each other.

See my answer to him above. The feature he is talking about isn't a firewall, but a form of sandboxing. Just as systemd does apply restrictions to sandbox and limit the privileges of an application deployed with it, it can also restrict its internet access.