tag 672296 - moreinfo stop
Hi Jonathan On Thu, 2012-06-28 at 13:59 +0100, Jonathan Wiltshire wrote: > severity 672296 minor Can't really agree with that (but also don't like to play severity-wars) and going to forward it to the security team once I have time. > Calling 'stop' in the init script does not flush the rules (in fact it does > nothing but emit a warning). Therefore: > - stopping does not remove rules > - descending into runlevel 1 does not remove rules Yeah, sorry... I didn't meant to say that you are doing this right now in code, that was just general thinking what should be done. I'm fine with having the "stop" action on the init-script and it doing nothing but printing a warning. I just don't see why you add this then to the LSB headers? It makes no sense but the init process (a bit) slower, both, on configuring it (insserv) and on invoking the stop levels. I've missed to add that point in the list ;-) > The only time that rules are not loaded is when the system is booted into > level 1 to diagnose problems, and I believe that this is an exceptional > situation and the administrator wants minimum influence on their work. I also think this is a bad idea. Why? - it opens windows for attacks; IIRC networking is not stopped in level 1, and even if it would, it's easily started again and easily forgotten at the same time, that the rules were never loaded. - I think there shouldn't be a semantic discrepancy between going straight to level 1 when booting and later going manually to init 1. - If the rules are really unwanted (as you said when problems or recoveries are going on), the sysadmin can just easily clear them himself; and if he's not able to, he probably doesn't use iptables and/or iptables-persistent at all. It's just a bad thing for us to decide for him, whether he want's that or not; because when installing the package, the user rather just says "i want it". > This is difficult to achieve with the curent init model. I agree, but this doesn't mean that we can just close our eyes and blame the init system. So long we still use sysvinitrc and nothing event based, we should at least try to make things as safe as possible. Again, see my arguments from the initial mail,... and again, S is not perfect, but much better. > Other services should never declare a depends on a firewall, this is > fixing the problem from the wrong direction. It's up to the local > administrator to protect the box *as they see fit*, it is not up to > packages to require it. Phew.... well a) many packages simply do it, be it a good idea or not (and I don't see why it should be a particularly bad idea, especially for packages who depend on it by definition, like fail2ban). b) I don't see how the local admin should do this (well except by modifying the LSB headers himself, but that introduces other problems). So what would be your suggestion here? > > The best solution would be, if iptables-persistent could reverse-depend > > on the networking initscript. > > But I guess this is not possible, as iptables rules cannot be loaded before > > networking runs, right? > > So we need another way to secure, that iptables-persistent comes directly > > after networking. > > This is a worthy ideal to reach for, but until there is support in the init > systems it cannot be achieved (and hacks in iptables-persistent are not > going to help that). What exactly do you think is missing? > Do you therefore agree that this bug can be closed (perhaps reassigned, but > I would rather clone it in that case)? Well, quite obviously not ;-) As said, I'd suggest to go back to previous values for the LSB headers and to try to make the rules loaded as soon as possible. IIRC, you're already back to deciding whether to load the rules based on the existance of the rules.v4|6 files, right? For some you used something in /proc or /sys for this, but I think that this was rather tricky and perhaps dangerous (I had the case, that the rules never loaded then),... even though the idea itself was nice. So, I'd really hope that my above suggestions convince you and make it in for wheezy. In addition, I'd suggest to pull this discussion over to debian-devel, I guess we may get good input there, on how things could be made 100% safe/perfect in the future (at least with newer init systems). Best wishes, Chris.
smime.p7s
Description: S/MIME cryptographic signature
