[systemd-bugs] [Bug 80169] please introduce more special targets for facilities like entropy, or netfilter rules

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80169

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.net> ---
Hi Lennart.

First, I didn't knew about network-pre.target yet... reading it's
documentation:
                                        <para>This passive target unit
                                        may be pulled in by services
                                        that want to run before any
                                        network is set up, for example
                                        for the purpose of setting up a
                                        firewall. All network
                                        management software orders
                                        itself after this target, but
                                        does not pull it in.</para>
it seems to me, that it's not much better than network.target itself...

It's very vaguely defined what it is... actually nothing is defined, just the
info, that it's before network is up.

So depending somehow on network-pre.target can in the end mean that you pull in
anything or nothing... starting from:
- netfilter rules
- local recursing nameserver running
- fail2ban running
- etc. pp.

So I really think that design wise, the whole network*.targets are rather
unfortunate... especially since they're not well defined.


As I laid out in the thread at the Debian list,... there should be really
specific target which is just for "netfilter rules loaded".
Or call it technique-neutrally "packetfilter rules loaded".... and it should be
really defined to be just that.


On special problem, which is IMHO not solved with something like
network-pre.target is the following:
I think we should basically teach/push writes of unit files to do things right.
For netfilter rules I'd say this means the following:

- they're _tried_ to be leaded very early in the boot process
  => the whole system (from user sessions to anything else) should be protected
already
  => if the author of some daemon's unit file forgets to explicitly
Require=netfilter.target (or whatever we call it)... the daemon will still be
safe.
  => therefore,... such netfilter.target should be
WantedBy+Before=sysinit.target

- but we don't want the boot process to fail, just because the loading of
iptables rules failed (they might have a typo)... I mean from a security POV
I'd personally rather want it to fail, but I guess one cannot convince people
of that... therefore, I'd have chosen and WantedBy= instead of RequiredBy=
above.


- But for any of the typical networking daemons (postfix, httpd, or maybe
GNOME's VNC server) I think we should teach/push people to the behaviour that
these services don't even start up, if the rules loading failed.
Having a typo in the netfilter rules can happen easy... and it will put the
whole system at risk, if services depend on it for their security.
So not staring these daemons in such case seems to be easily justifiable...
after all... people will more or less immediately notice and simply correct
their rules.

=> Therefore, unit files of such daemons/services should more or less
_generally_ contain a Require+After=netfilter.target
I really think that this should be advertised by you guys,... in whatever
example unit files or documentation you provide. Actually your G+ and blog
posts seem to be a good place for such advertisement.

This is also the point where I think the network-pre.target idea fails... since
this can imply more or less "anything before the network is brought up"... unit
file authors will be very reluctant to add it.


Technically, the actual services that provide the netfilter rules loading, e.g.
Debian's netfilter-persistent or packages like ferm/shorewall etc. should than
set a RequiredBy=netfilter.target.

=> If none of such packages is installed... than depending (regardless of
whether {Wanted|Required}[By]) will cause no harm...
=> If any of such packages is installed, than if _any_ of them fails,.. the
daemon (e.g. postfix) won't be loaded => great
=> For netfilter loaders... these packages usually will conflict anyway each
other.
=> If an admin really really want's his daemons to start, even if e.g.
netfilter rules are not successfully loaded - fine... he can very easily do
this and slectively change the RequiredBy=netfilter.target of packages like
netfilter-persistent/ferm/shorewall.

Everybody should be able to be happy with that:
- more secure out of the box (because services are not loaded if rules loading
failed)
- if it's BCP that netfilter.target is added as Requires+After= to any
dameon/software that does any networking... than this should become common
practise as we've had $network on literally every daemon with sysvinit
- admins can easly change the hard reverse-dependency of ferm|shorewall to
netfilter.rules to a soft one.
- services don't need to depend on network.target or network-pre.target...
which may (or may not) pull in much more than a service actually wants. I mean
the more such rather vague meta-targets (like network.target) we have... the
more flexibility is lost in our boot and dependency tree.


That being said... one can easily imagine that people want something like a
hypothetical netfilter.target also for software like fail2ban.
E.g. I might be so paranoid, that I only want my services to be started if
fail2ban runs... and I really don't want having to edit the rules files of all
my daemons.

So perhaps one could make the netfilter.target to be a
"network-secured.target", clearly defining that this contains any
services/stuff that secure the network, giving examples like:
- netfilter rules loaded
- fail2ban
- ...

I would however probably clearly except that such netfilter-secured.target
contains things that set up connections (e.g. strongswan, openvpn, etc.)
All these are again quite heavyweight... and if an admin's system depend on
e.g. ipsec for security... he should implement this via netfilter rules anyway.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140618/11e8ba8f/attachment.html>