[systemd-bugs] [Bug 80169] New: 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

          Priority: medium
            Bug ID: 80169
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: please introduce more special targets for facilities
                    like entropy, or netfilter rules
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: calestyo at scientia.net
               URL: http://lists.alioth.debian.org/pipermail/pkg-systemd-m
                    aintainers/2014-May/002174.html
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

Hi.

Some weeks ago, I've started an (yet unfinished discussion) at the mailing list
of Debian's systemd maintainers:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-May/002174.html


The original motivation was, how it can be assured that netfilter rules are
loaded before any networking is done by the user and/or daemons.
Debian's iptables package doesn't have an rules loader itself (like e.g. RedHat
has), but there are several other packages which can do this, e.g.
netfilter-persistent, ferm, shorewall, etc..
Of course, these packages could just reverse-depend into some already existing
special targest like basic.target, sysinit.target or network.target.

But none of that seems really well suited... after all... one of the core ideas
of systemd is to start only necessary things and only when they're needed...
But why should some daemon need to depend on e.g. network.target (which implies
all kinds of things)... if it just wants to make sure that netfilter rules are
loaded before it is started... while e.g. any network interfaces will be
dynamically detected and bound to when they're brought up.


The problem is IMHO more general then netfilter rules only:
A system has facilities which are very important (typically for security) but
which daemons don't directly depend on (in the sense as e.g. some service xyz
may depend on the PostgreSQL unix socket being there in order to start at all).

The most prominent example are surely the netfilter rules: depending on how
services are used/configured it may be extremely important for security that
netfilter rules are _successfully_ loaded before the services start up.
This may include access constraints based on IP address ranges or things like
assuring (via netfilter) that some traffic is only accepted (outgoing and/or
incomming) when it was IPsec'ed... or secured via some other VPN.

But netfilter is not the only security-facility.
Other things could be for example services that provide more/better entropy.



I think a framework for the most important of such facilities should be
provided by upstream, so that a common practise is established how unit files
for daemons depend on such facilities.

Several questions/issues arise here:
- which targets/units shall we provide, so that only the least necessary stuff
is loaded (i.e. it's IMHO a bad idea to just put everything into
networking.target)
- when we have an abstract target, that provides e.g. that netfilter rules are
loaded, how do we allow multiple different actual services (e.g. ferm,
shorewall, netfilter-persistent) to actually implement that abstract facility
- how can we make sure that such important things are Wanted= very early (I
mean mostly everything in the system should have netfilter rules in place, not
only daemons but also user sessions or other things of the early boot
process)... while they are definitely Required= to for daemons to start at all?
- how can we allow admins to easily change that hard (Requires=) to a soft
(Wants=) dependency, e.g. if an admin is fine with that a daemon starts even if
loading netfilter rules has failed (which is very stupid and shouldn't be the
default, but people will cry out if it's too difficult to them to go back to
their "good" old behaviour).


In the aforementioned mailing list thread I discussed about just these things a
bit with the Debian maintainers.
Those two mails, probably contain the main ideas and proposals:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-May/002174.html
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-May/002184.html

Would be great if you guys could read into that and perhaps it can be discussed
then whether/what can actually be done in systemd upstream.


It's not really much that needs to be done from a technical POV,..
- some special targets for facilities like "netfilter rules successfully
loaded", "entropy services started", etc. should be defined
- such facilities should be WantedBy+Before= the early boot process (i.e.
sysinit.target)
- a policy or BCP document should be written, where people (those who write
unit files for serivces) are advised things like.. "if you're service does
networking, then you should
Requires=netfilter-rules-special-target-with-some-yet-to-be-found-better-name.target"...
if you need good entropy you should Requires=entropy-services-loaded.target"
- end users / admins should find documentation how easy they can change the
behaviour that their daemons would still start up, even if e.g. loading of
netfilter rules fails (which I think can be fairly easily done _without_ the
need to change all the Requires= in each of their daemons) (but see the
aforementioned thread about this).


Also I think, people should be told that using network.target is bad style -
well at least I would think it is.
You say yourself, that it's not well defined, so by depending on it you can
basically pull in anything that is somehow networking related.

In a modern world, daemons discover e.g. network interfaces and local addresses
dynamically and bind to them... not longer depending on all the NICs already
brought up.
So services shouldn't need depend on networking.target unless they need to.
But even in the modern world, services should (for security reason) most
definitely want to have netfilter rules _successfully_ loaded _beofre_ the
daemon starts an listens... but just for that one shouldn't need to wait for
everything else that might be implied by network.target (DNS, interfaces up,
whatever).


Cheers,
Chris.

-- 
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/20140617/0a81cbc5/attachment.html>