Hi. First, this is not about bashing systemd (I'm actually mostly in favour of it and use it since a long while)...
Now that it get's the default init in Debian... and becomes more and more mandatory (e.g. that other stuff like policykit basically depends on it) I wondered how Debian solves the issue with security related dependencies for services? What do I mean? Well units in systemd may have some dependencies (Wantedby, Requires, etc.) so e.g. if syslog.service starts, it Requires syslog.socket and if the socket itsn't there yet (or failed),.. systemd won't start syslog.service. Better even, if the unit file would have forgotten about the socket, rsyslogd itself would simply fail, or does the right thing itself. In contrast to that, we have "passive" dependencies which the services themselves usually never check (or even cannot really check) for... typically such, which are security relevant. Examples: I) initialised random seed Basically everything that uses /dev/urandom (everthingy with crypto and thus most network services or programs that run completely locally in user space) will want to have /dev/urandom properly seeded with the stored seed from the before the last reboot. I'd guess that is done by systemd-random-seed-load.serice, which in turn is wantedby sysinit.target, thereby it comes before basic.target etc. pp. But is it really guaranteed that "normal" daemons come after one of these? I mean most of my services units show to depend on basic.target... but not all. So I guess there is no hard barrier imposed by systemd where it says "normal stuff" (whatever that is) comes after seed-loading... and it's up to the unit-file writer, to do the right thing. But obviously this can be quite difficult... take cryptsetup.target... cryptsetup (i.e. the userland tool) uses urandom (well at least in some version)... now of course cryptsetup.target is about making the volumes available (which makes it somehow a misnomer, IMHO, and it should rather been called dm-crypt.target).. but there are dm-crypt modes which require entropy for writing (e.g. salts?) or there might be such in the future... Has it really been tested whether nothing of this would need an already seeded /dev/urandom? II) entropy providing services I mean things like haveged or perhaps the services for TRNGs like the Simtec EntropyKey, for which the daemons are in Debian. People may likely want that these are loaded before their entropy using services/programs... and this is not just about providing more entropy, but about providing better entropy... I think neither currently (sysvinit) nor in systemd it's really guaranteed that these services are up and running... before normal stuff kicks in... Especially it's typically not enough for them to just run, but I guess a TRNG would need some small time (probably much smaller than 1s though) to feed something useful into the kernel entropy pool. III) iptables, VPNs, IPSEC, DNSSEC I guess it's quite easy to imagine that either of this might be security critical. - one might depend on some IP based blocking since then only some trusted local addresses would have full access to some ports where services are provided openly. - want may depend on some local DNSSEC caching/recursing server to be run, which guarantees the validity of DNS,... services running on the machine may depend on that for security reasons... but if the local DNS server doesn't run,... the system could perhaps pick some other fallback provided by DHCP, or even locally configured (that should however only be used, when services requiring secured DNS are not running). - one might depend on ipsec for secure communication between services Like I have some ejabberd cluster running, each on a different remote site (basically for redundancy)... now each of the ejabberds will communicate with the other but completely unencrypted. So I've set up ipsec to encrypt the traffic between those tow. But ejabberd itself doesn't do any check whether ipsec is on... if nothing has been negotiated it will just use the same IP addresses but any traffic is then of course completely unsecured. Bad. Now at least I and III have been more or less simply "solved" with sysvinit. That was so much less powerful wrt it's dependency graphs... it was much more serialised... and: (I) simply happened so early in the system (run level S) that networked services were not running yet and that no single/multi user sessions were available (such you couldn't run cryptsetup(1) and e.g. create new volumes using bad /dev/urandom). (III) ... well basically all daemons simply depended on $network ... so the only thing needed to be guaranteed was, that at least your iptables run before that (which could be easily done and verified in the few programs like iptables-persistent). In my iptables rules, I could then e.g. block any non-IPsec'ed traffic between my two ejabberd server's addresses. Obviously this gives a lot serialisation (which is bad)... but it's easy to makes things secure (if a service like ejabberd would have missed to depend on iptables-persistent, it would have been fine, since it most likely was not forgotten to make it depend on $network, which had the reverse-dep by iptables-persistend.... and if it forgot to depend on $network and would have been run before... no problem either, since no interfaces would have been up yet). With systemd everything is more powerful and better... we try to serialise less, run more things in parallel and as early as possible. unit-file writes will want to avoid to depend on something like networking.target... Perhaps I miss something, but are we currently on the safe side, that e.g. netfilter rules are loaded before any networking is done? And I really mean in a sense: If loading e.g. iptables-persistent failes for whatever reason (typo in the rules file?)... no further service that does and local-only or remote networking should not even be tried to load, since that might already be a security hole. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
