systemd and "passive" security dependencies for services?

[Christoph Anton Mitterer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5165 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20140518/05c53ef0/attachment.bin>