What do you mean it talks to the network? Can you give some reference?
By default systemd includes journald, rather controversial (and mentioned in a comment on this thread) picked binary logging (harder for humans) and much less robust in the face of a small corruption, and ignored encryption. I believe it doesn't support encryption (by default). This replaces more robust solutions (by default) like syslog-ng and rsyslog that have long histories of battle tested real world usage.
resolved replaces the local DNS resolvers, and at least for awhile ignored DNSSEC. This is particularly bothersome since it is such a security sensitive daemon. Sure you can disable it and pick unbound, but it's not default.
timesyncd is a time daemon, replacing NTP, another security sensitive app. Not that NTP is a paragon of security, but various projects have arisen to improve things.
networkd is a replacement for DHCP and similar for IPv6. Again not nearly as nice or secure as existing solutions.
So basically decades of developer work, security audits, and competition among network services had been ditched and is now part of systemd and a typically cavalier attitude towards security.
There are good parts of systemd, it filled a need. But this swallowing of security sensitive network services really bugs me. Being able to be compromised so early in the process and the tight integration going against the idea the unix philosophy of using minimalist modular software. Normally I'd run unbound as a non-root user with access to read few directories, and write to even fewer, DNSSEC enabled, and logging via syslog (human readable). By default on an ubuntu 20.04 (and 18.04 before that) I'd have issues with dns failures... till I replaced the systemd resolver. I'd mention it to other admins and they would shrug and mention that systemd sucks.
The name enumeration alone should ring bells.
There's always more that can be done, but https://github.com/systemd/systemd/tree/master/src/fuzz contains more than most of the aforementioned combined.
As for how your run your alternative services as non root, you may wish learn about what the contents of this file means: https://github.com/systemd/systemd/blob/master/units/systemd... or this one: https://github.com/systemd/systemd/blob/master/units/systemd...
Can you point to a commonly used initrc that comes even remotely close?
You should also read https://systemd.io/JOURNAL_FILE_FORMAT/ and NetworkManager, which is what Ubuntu uses.
By all means bash away (pun intended), but I keep seeing these points go uncontested and they're not very well founded.
Sure, bind has a terrible security record, and that was part of the reason why people started writing more secure replacements like unbound.
NTP has a terrible security record, and that's part of the reason people started writing more small secure replacements like NTPsec and chrony.
Similarly sendmail's security issues resulted in improvements like postfix, which hasn't been swallowed into system yet, mostly kidding.
Linux often has multiple implementations for a given service and ease of use, performance, security and related allows them to compete. This is a sign of a healthy ecosystem and generally I think it's working well.
However systemd, by rolling this functionality into systemd subverts that system and the vast majority of systems will just accept the defaults. It also makes systemd huge and complex, last I looked there was somewhere around 5% of the lines of code in systemd than the entire linux kernel which I find scary.
Second, systemd does not mandate using any of these components apart from `journald` and `logind`. You can pipe journald into any syslog daemon of your choice, there's a config option to do so. If you've got issues with logind I can't help you there. I don't know what it was intended to replace (consolekit, I think?) but I do remember it was badly maintained.
Third, a vast majority of deployments do _not_ accept defaults. I know that both Red Hat and Debian go for third party network managers (networkmanager and Debian's ifup/ifdown stuff) and rsyslogd was there on a default install of both Debian Buster and CentOS 8 iirc.
Finally, I repeat, systemd is a monorepo which contains many programs. Sure, you can argue about how they're tightly bound, but I can point you towards FreeBSD/OpenBSD if you'd want them to be broken up into separate repos to be more "unix-y", and if you look at systemd PID1 it's a fairly small binary which doesn't seem to offer many security holes.
Would have they remove the "systemd-" prefix from all side binaries and marketted them as independant projects on the website, made them usable without systemd and maybe on sub repositories, would have the systemd project just had to explain "yes we rewrite ntp, dns, etc, why not ?"
Instead they received complains about a "bloat ware" while often rewrites of industry-standard by unknown/junior people are acclaimed on HN :)
Even better, they could have integrated chronyd or others by creating "systemd integration standards" and submitting patches to these projects to gain community support and permit an easy switch to one or another implementation and let the users chose. Though it s still already easy to use something else than timesyncd on centos at least, thanks to systemd project and distri maintainers too :)
It isn't comparable with typical rewriting of industry-standard by newbies.
It's not ideal when looking at the whole environment, but specifically for our services - we've got the choice.
In any case it's the default behavior of systems that should be secure and systemd is the exact opposite of that.
Source: https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...
Original comment follows:
I'm... not sure I understand. VPNs would only work after your physical interfaces are up, right? So if you want your firewall rules to be applied before a VPN interface comes up then you'd be perfectly fine with network-pre. From the page I linked in the comment you replied to:
"network-pre.target is a target that may be used to order services before any network interface is configured. Its primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up. It's a passive unit: you cannot start it directly and it is not pulled in by the the network management service, but by the service that wants to run before it. Network management services hence should set After=network-pre.target, but avoid any Wants=network-pre.target or even Requires=network-pre.target. Services that want to be run before the network is configured should place Before=network-pre.target and also set Wants=network-pre.target to pull it in. This way, unless there's actually a service that needs to be ordered before the network is up the target is not pulled in, hence avoiding any unnecessary synchronization point."
So ideally you'd run your VPN service after network-online.target has been reached, which would certainly be after the firewall rules have been applied.
The great thing about persistent interface names is that if you know the names of the interfaces which are going to be coming up, then you can set up a firewall before any of them come up. Which takes care of dynamic VLAN interfaces. You can use IP addresses or blocks to refer to them in your firewall config, am I right?
If you think I'm unable to grasp your situation, can you give me a more detailed example?
This is a big point. All of the systemd systems I've been exposed to in the wild have non-deterministic inits, i.e. if it takes longer than average to boot up once (A problem I had a few times), starting it again doesn't replicate said problem. If the network craps itself when booting sometimes, that problem is variable so it's impossible to tell if you've fixed the problem, and it was what you suspected, or if it's something else and you only think that you've fixed it.
On the other hand, my alpine system consistently boots up. If it errors once, it will error consistently enough to allow tracing of the cause, but regardless, it has never had a problem on boot.