systemd and "passive" security dependencies for services?

[Tollef Fog Heen]

]] Christoph Anton Mitterer 

> On Wed, 2014-05-21 at 16:35 +0200, Tollef Fog Heen wrote: 
> > > 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.
> > sysvinit isn't serialised today either.
> Sure... I mean we have parallelism as well,... and I guess all what I'm
> writing about is less about technical stuff (i.e. what would the
> respective init dependency framework allow)... but rather about "how is
> it done in practise with the respective scripts/units".
> 
> And there I've had the impression that things in sysvinit are set up
> more serialised (i.e. that there are things like $network, where de
> facto any service depends upon, when it does networking).

$network is translated to network.target for LSB services, so it is in
fact the same thing.

You're pointing out that «the network is up» is ill-defined.  That is a
correct observation and technically never true in a dependency system, since it might change at
any point.  However, that's not a very useful definition and so systemd
provides it for software that doesn't know how to deal with dynamic
networks. 

> - it seems not really be well defined what it does

Just the same as today, it's ill-defined.  Does it mean you can bind to
an interface?  Other than localhost?  Link is established?  IP address
set?  You can bind to all the interfaces?  You can talk to the default
gateway?  Your routing table has somewhat converged and you can speak to
most of the internet?  Something else?

The answer to what it means is «it depends». 

For reference, the LSB definition is «$network: basic networking support
is available. Example: a server program could listen on a socket.»  So
it does not say anything other than «you can listen on a socket», but
that's not what applications treat it as.

> - it's a passive unit, so AFAIU it's not to be pulled in by the services
> consuming that functionallity (i.e. webserver) but rather the provider)?

I don't know what you mean by passive unit.

> - it's more about networking, less about netfilter,... so I think there
> are services for which iptables need to be set up before they start
> running, but where the interfaces, DNS, etc. don't need to work yet (or
> at all, if there is just networking on the loopback)

loopback works before any services are started, so that you don't have
to worry about.

There's nothing in the LSB definition that says «firewalls are up».  If
you want that, have a ferm.service (or iptables-persistent.service if
you prefer that) that has Before=network.target and it will run before
you have «useful networking».

> - there seem to be only few services that do networking which actually
> somehow depend on it...

Services are hopefully rewritten to not having to rely on it.

> So I guess one thing must be guaranteed... if one uses e.g.
> iptables-persitent to load the iptables rules,.. than seervices that do
> some networking must start after it,... and ONLY if iptables-persitent
> was loaded successfully.

No, you need the interface not to be brought up before you apply the
iptables rules. That's completely orthogonal to when the service is
started.

> AFAIU systemd, than right now we have e.g.
> network.target is before iptables-persistent...
> But this doesn't guarantee at all that iptables-persistent is started,
> does it?
> Wouldn't one need some "Requires" for that?

If iptables-persistent wants to run before network.target, it should
declare that by doing WantedBy=network.target and Before=network.target

> I think best would be if there were some more such special targets like
> network-security or so...
> All services that do some networking should Require=/After= that... and
> that target in place should pull in those of the installed services like
> iptables-persistent...

Why should security be a bolt-on?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are