reopen 775544 stop On Mon, 2015-01-19 at 10:56 +0100, Arturo Borrero Gonzalez wrote: > First, when stopping a service, I expect all effects of the service to > disappear. Well but a firewall isn't a service like a daemon like postfix. It's more like the initial-entropy-seeding of urandom on boot... something that needs to be done, but something one typically never wants to stop, and especially not accidentally.
The same is true for your nftables "service"... it's not the firewall itself, which is part of the kernel an which one cannot stop that easily... it is only the loader for the rules, thus a stop action would mean "stop loading the rules" - well that's already done so it can't be stopped anymore. Flushing, especially when this means the unsafe default of "everything accepted", seems to be quite a bad effect for stop. > This is the default behaviour of the nftables service. > What you are suggesting, applied to other services, is to stop > networking but keep interfaces working. No I don't think that this is what I recommend, especially since your service doesn't start anything which is really the firewall... it just loads the configuration for the already running daemon > Or stop a daemon but let > current client connection to end. ... which would however be also not so uncommon... see e.g. sshd, when you stop it, you already running sessions still live on. I guess it's a case-by-case question,... and one should usually decide based on common sense and so that people don't shoot into their own feet by accident. Flushing the firewall rules is definitely such a pitfall, where people would shoot into their own feet (usually one doesn't want to unload the rules). It's like with ssh,.. just because one stops/restarts sshd, one doesn't want the sessions to die. > I'm sorry, but I disagree. For me, stopping a service means that no > further effect of the service happens. Well, even if you take it like that, than my point is right (no further rules loading takes place)... and actually your current scripts do just the opposite of what you say you want: Further effect happens, i.e. the rules are once more changed (to an insecure allow-everything value). And equalising the nftables init script/service with the kernel nftables systems.. thus believing the illusion that the script would stop the actual service (i.e. the kernel nftables)... is anyway wrong. You don't stop it you just open up it's configuration to allow everything - which is IMHO actually more the opposite of "stop"... if you insist on mapping started/stopped to accept/reject packets. > Why would anybody to stop the firewall service but keep the ruleset in > place? Which is the effect of stopping the firewall then? Again, as said,... you don't stop the firewall it's still in the kernel. The only thing you do is to once again change it's configuration on stop. This is btw also the reason why iptables-persistent doesn't call it's scripts/services "iptables"... because one would get the false impressions that iptables was stopped/started. > Second, this is why the service is not enabled by default. Well a) this may come sooner or later... > The admin > should manually activate the firewall service. > So there is no such behaviour unless you manually do something. ... and b) just because the admin has to enable it manually, there is no reason that we provide a script which easily tricks him into opening up his firewall. > For the security issue you mentioned, is as easy as stop firewall the > last in the shutdown sequence. Which is however not the case right now, and even if it would be,... then this is just a great source of possible errors... just one tiny misconfiguration (perhaps even in another unit file), and the firewall might be opened up while real services (which depend on it for their security) are still running. Also, you seem to completely forget the restart case. In systemd restart is handled as stop/start. So when people think they would just reload the modified set of rules, then with your current behaviour of flushing the firewall rules on stop, you actually open up a short window in which the system is again completely unsecured. > But again, since the service is not enabled by default, you can do > whatever you want when activating the service. Everyone can always do what one wants... one can compile nftables manually and write a own unit file for it... But that's not why we have distributions, where we try to provide people to give sane and secure code. Therefore, reopening until discussion on this matter has come to an end. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
