severity 672296 minor tag 672296 + moreinfo thanks Hi,
On Wed, May 09, 2012 at 10:20:15PM +0200, Christoph Anton Mitterer wrote: > stop (now 0 1 6): > - I don't think iptables should be ever stopped, in the sense of > clearing the rules set up by the user. > Especially as it's totally undefined what "stopped" means. Is it allow all? > Is it deny all but traffic on loopback? > - It's further not guaranteed that there is no networking in single user mode. > So stopping it for run-level 1 may open holes. > - Does it make sense at all to stop it on 0/6? I don't think so, at least > unless > the chains are stored. > Suggestion: Go back to the previous (safe) default of > # Default-Stop: 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 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. > start (now 2 3 4 5): > - Again "S" was safer default, though not perfect. > - Networking may already take place in runlevel S, which is now (even more) > unsecured. > - Starting this in 2 3 4 5 means it can be started basically at and time > during these runlevels. > But other services may already depend on iptables rules in place. > My own example is that of depending on rules to be in place, that > allow only IPsec connections to/from certain destinations/sources. > These connections are used by level 2/3/4/5 services, e.g. ejabberd. > With the new runlevels 2/3/4/5 of iptables-persistend it's not guaranteed > at all, that it runs before ejabberd comes in place. > Even worse, giving that people usually allow ESTABLISHED connections, > such a pre-iptables-rules-loaded connection may stay forever unsecured. This is difficult to achieve with the curent init model. > - Typically other services don't depend on iptables-persistent. > > On can now argue, that other services should depend on itpables-persistent. > This is tempting, but a) it'll probably just never happen that this is adopted > b) it always leaves the gap that some new package misses this, especially > as there are so many "firewall" packages in Debian. 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. > 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). Do you therefore agree that this bug can be closed (perhaps reassigned, but I would rather clone it in that case)? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 <directhex> i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
