<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - please introduce more special targets for facilities like entropy, or netfilter rules" href="https://bugs.freedesktop.org/show_bug.cgi?id=80169#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - please introduce more special targets for facilities like entropy, or netfilter rules" href="https://bugs.freedesktop.org/show_bug.cgi?id=80169">bug 80169</a> from <a class="email" href="mailto:calestyo@scientia.net" title="Christoph Anton Mitterer <calestyo@scientia.net>"> Christoph Anton Mitterer</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>