systemd and "passive" security dependencies for services?

[Christoph Anton Mitterer]

Hi Michael.

On Wed, 2014-05-21 at 00:14 +0200, Michael Biebl wrote: 
> I have no idea what you mean with passive dependencies.
Well I hope I've had that explained by the examples I gave.

What I mean was:
Usually none of the services depends (directly) on <random seed loaded>,
or <TRNG is running> or <iptables rules loaded> or <IPsec
established>...

One goal of systemd was always to start services (if they need to be run
at all) as early as possible... which is why it even tries to load stuff
when not yet all filesystems are there, etc. pp., right?

By looking at that goal (which is a good goal of course) we "loose"
however that strict serialisation that we more or less had with
sysvinit.
In sysvinit, each services simply depended e.g. on $network, when he did
networking... and by that one could already assure, that iptables rules
were in place,... even if the maintainer of the init-script forgot about
iptables.

With systemd, AFAICS, we don't have anything directly similar, or do we?
So all the maintainers would need to make sure that their unit files
depend on the above <...> stuff.
Quite error prone...


See what I mean?
E.g. in the sysvinit script for postfix,.. the maintainer didn't have to
add Required-Start: iptables-persistent... that was already implicitly
guaranteed by $network,...
Is something like that the case for systemd as well? Or do we have to
closely check all new stuff that supports systemd, whether we need to
add kind of virtual targets where they depend on, like
"secure-networking",... which in turn pulls everything in that the admin
has configured to be necessary for securing networking (e.g.
iptables-persistent or something similar, strongswan, openvpn or
whatever).


> There is nothing magic regarding dependencies.
Sure... and while design-wise that's great... security-wise it's a
"problem"... as in sysvinit,.. one (automagically) got e.g.
iptables-persistent since everyone remembered to depend on $network...
when networking was used.... but I guess many services would forget to
depend about an ORed list of all the packages tat serve as
netfilter-rules-loader...


> I guess the only thing you need to know is, that there is a flag called
> DefaultDependencies=yes|no.
> The default is yes, if not specified.
> With this property set, units get a default set of orderings and
> dependencies.
> IIRC they slightly differ depending on the unit type, e.g. service or
> socket.
> It's comparable to services being started in rc2 and implicitly
> depending on rcS.
Uhm I read the description of DefaultDependencies in
systemd.target(5)... but as far as I understand, this only tells whether
the targets load their dependencies or about like that.

It doesn't assure that e.g. iptables-persistent is always loaded before
e.g. ejabberd,.. unless the unit-file writers thought about directly
depending on it, or indirectly on something which depends on it or is
wanted-by it.


Thanks,
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://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140521/fe4bd762/attachment-0002.bin>