systemd and "passive" security dependencies for services?

[Tollef Fog Heen]

]] Christoph Anton Mitterer 

> On Thu, 2014-05-22 at 16:40 +0200, Tollef Fog Heen wrote: 
> > $network is translated to network.target for LSB services, so it is in
> > fact the same thing.
> Sure... 

What's the deal about your use of ellipsises all the time?  It looks
really weird and I'm not sure what you're trying to communicate by using
them.

> > 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.
>
> Sure... but that's how it is... I guess it's absolutely sure that there
> will always be software, which doesn't use e.g. NM (and given the issues
> I have with NM, I'm actually happy about that).
> But even if all software _would_ use NM (or something similar)... NM
> doesn't take care about e.g. netfilter rules.

This has nothing to do with NM.  Interfaces come and go on machines
running BGP daemons for instance.  Or if you use IPv6 with
autoconfigured addresses.

> > 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?
>
> Sure... and don't get me wrong... I never tried to show that systemd is
> worse than sysvinit.

It's not about better or worse.

> The only "advantage" that we had with sysvinit... things were that
> "legacy"... and all networked services usually depended on $network...
> that from a security POV we got the "netfilter rules already loaded" for
> free and "for sure".
> It wasn't a "hard" for sure... if some init-script would have forgotten
> to depend on $network,... then same situation... the service might have
> gotten loaded before netfilter rules were in place.
> Neither was there any guarantee that the rules were successfully
> loaded... just that they were tried to be loaded before the service.

The same goes today.  Depend on network.target and you'll have the same
things as you have today.

> > > - 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.
>
> Well the upstream documentation I've referenced uses that phrases...
> claiming network.target was passive, while network-online.target was
> active.

I did not find the phrase in the NetworkTarget web page at least.

> > > - 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.
>
> Sure... what I meant was rather:
> Even though it's probably highly specialised... there may be setups
> which require the netfilter rules to beloaded even before the loopback
> is up.
>
> Though admittedly I haven't seen such...

I'm not able to come up with a non-contrived case for that.  Sure, if
somebody has compromised your init system, they can do bad things, but
that's not because they can talk to loopback, it's because they've
compromised your init system.

> > 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».
>
> Okay but I though network.target itself is rather something legacy... is
> it really like "policy" that all services that do networking depend on
> that?

If they need it, sure.

> > > - 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.
> That's one of the problems...
> It's good if a service doesn't depend (i.e. the daemon doesn't crash or
> whatever) if networking isn't there.
> Therefore most services would only say:
> Wants=networking.target

Note that Wants/Requires does not imply ordering.

> But if we do like you say above (i.e. iptables-persistent has
> Before=network.target)... then we have no real guarantee that the rules
> are up, when the service that Wants=networking.target starts.

That is why they should also have After=network.target

> > > 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.
> > 
> > you need the interface not to be brought up before you apply the
> > iptables rules.
>
> Sure.. I didn't claim that, did I?
> Actually the rules must be loaded BEFORE the ifaces are brougt up.

You claimed that it was the service start time which was interesting.

> > If iptables-persistent wants to run before network.target, it should
> > declare that by doing WantedBy=network.target and Before=network.target
> Wants/WantedBy is not enough here...
> According to the docs:
> Wants= 
>            A weaker version of Requires=. A unit listed in this option will be
>            started if the configuring unit is. However, if the listed unit
>            fails to start up or cannot be added to the transaction this has no
>            impact on the validity of the transaction as a whole. 
> 
> So  that means loading iptables could fail, but the services would still
> start => security issue

If you require something harder, use RequiredBy.  Note that it might
lead to stuff not loading if your iptables rules fail to load for some
reason.  In some setups, that might be what you want, in other, you'd
rather have SSH running so you can log in and fix it.

> > > 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?
>
> Well I guess everyone being only somewhat security conscious will agree
> that it's better to not have some service started at all (which will
> usually be noted immediately) than to have it started unsecured (which
> usually noone notices that soon).

If you care about security you need to monitor it.  If you don't monitor
it, it doesn't exist.  And no, I'd rather have SSH running and no
iptables rules loaded than no SSH and no iptables rules.  One I can fix,
the other I can't (without physical or IPMI access).

> Can we agree on the following:
> 
> 1) daemons (postfix, postgresql, httpd, gdm3) but also the system as a
> whole requires some "things" with respect to security being present
> (let's take again "loaded netfilter rules", which is not only important
> when you run listening services but also on normal desktops, i.e. when
> you just have login sessions).

This is pretty vague, but ok.

> 2) These "things" must be in place, _before_ the service is used... e.g.
> netfilter rules must be loaded, _before_ the daemons start, _before_ the
> user could do any networking in his sessions, etc. ... or e.g. a TRNG
> must be activated, _before_ services want to use high quality entropy.
>
> If not, then one might have a short time frame, where e.g. postfix
> listens and networking is not secured... or where httpd makes TLS
> connections, but it still uses poor entropy from right after the system
> boot.

No.  In some cases, having that window where an attacker might attack a
surface is perfectly acceptable.  In other cases, it's a big deal.  It
depends on the context.

> 3) In systemd, we only want to start things when necessary... and also
> only want to pull in the least necessary stuff... i.e. if postfix
> auto-discovers new interfaces that go up and starts listening on them...
> we don't want it to depend on network.target (which already expects all
> the ifaces to be up)... but we DO want it to depend on "netfilter rules
> loaded".
> And having the netfilter rules loaded as an even (e.g. just before a new
> interface is brought up) just doesn't work in practise.
> So neither can we delegate that task to postfix, or to the
> program/service that brings up the interface (e.g. ifupdown, or NM).. we
> have to do it in the system start.

If having netfilter rules is crucial to postfix' security (which I
really hope is not true), then it should depend on having the rules
loaded.  If it's only a want to have it, use After=network.target and
Wants=network.target.

[...]

> So if I didn't miss anything in that example,.. one sees how easy it can
> happen, that security is missed out.

It's not black and white; not having the rules loaded for half a second
is «you don't have any security».

> Now if I'm right so far, I guess two questions come up for each of such
> "things" like iptables/TRNG/etc.
> a) When and how (i.e. via which units) should it be pulled in?

network.target.  If you want high-quality entropy, use /dev/random, not
urandom.

> b) What should happen, if the "thing" couldn't be started by systemd or
> if the daemon (if any) that runs "thing" fails/crashes.

Local policy.

> In my opinion, security always comes first, so I rather think that if
> e.g. iptables can't be loaded (perhaps because I did a typo) then my
> deamons should start neither.

In some cases, sure.  In other cases, no.

> I guess that's about the basic idea hope it works like that ;-)
> So the really important thing now is, that such behaviours are made BCP
> by you systemd maintainers... or otherwise there is little chance that
> one will see widespread and homogeneous use of something like that over
> all packages.

I don't think there's much we can do either way there, tbh.

> [Actually I always have some slight hopes that you guys find some time
> to also look over the unit files once packages get systemd support and
> to see whether it's just some plain conversion from the sysvinit script
> to systemd, or whether it really uses all nice features of systemd that
> would make sense for the respective package (well at least I guess that
> not all package maintainers are systemd geeks as well ;-) ).]

I know I won't have the time or interest to do so.  I suspect the same
goes for the other systemd maintainers.

[...]

> How do we handle network security "things" that run after ifaces are
> brought up? Like VPNs or IPsec (actually I don't know, whether it's
> necessary to have ifaces up for these to be configured, but I guess so).
> I handle that via netfilter rules as well (i.e. I forbid any traffic
> that is non IPsec'ed, which I consider to be security critical).
> But for some people it may be useful to have a "network-secure-foo"
> which is pulled in after ifaces are up (of course again the problem with
> "which ifaces does that include?")... and which could pull in things
> like strongwan.
> 
> But I guess this is a rather hacky thing and we should try to avoid it.
> If you need IPsec/VPN for security,... set that up in your netfilter
> rules (it's easy).
> If you need DNSSEC,.. simply don't add any resolvers that don't
> validate.

All of this is deep within local configuration.  Debian can offer some
defaults, but things like «don't allow non-IPSec traffic» obviously
won't fly in the default installation.  As a start, you would not be
able to do network installations.

> III) What about "passive" security programs like rhkunter|aide|samhain|
> tripwire etc. pp.?

Local configuration.

[...]

> Also, is there some way in systemd, that if one of haveged|ekeyd|etc.
> would crash, that everything that has some kind of hard dependency on
> "entropy-service.target" is immediately stopped?
> Then admins could configure their e.g. httpd to rather stop, when it's
> no longer guaranteed that "high quality entropy" is available.

You can use BindTo and related directives.  If you need high-quality
entropy you should use /dev/random and not /dev/urandom, though.

Lots of those targets can be supplied by the local admin or another
package. If you do that and convince people to use them, more power to
you.  We don't have the time and energy to do so within the systemd
team.

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