It's safe as pulling the network cable out of the computer is safe. You shouldn't rely on policy you should configure things in the first place so that all traffic is handled and not leave a shotgun trap in place that will blow your own brains out =/.

Implementing a default deny policy is part of the way you make sure that all traffic *is* handled.

I fail to see how having a deny at the top of your firewall rules is in any way similar to pulling out the network cable or shooting yourself with a shotgun. You're more likely to accidentally shoot yourself if you have an open firewall and then try to create a rule for every single type of attack on each port on your system.

No, it's a way of making sure all traffic is dropped. It's similar because it's not a method you should be using in the first place. If you have configured your firewall correctly you should NEVER need to rely on such a policy and I have never heard of people getting hacked because they had to open their firewall for a few minutes (not to say it can not happen but the likelihood of it, is very rare), on the other hand I have heard of hosting companies suffering customer losses due to having default deny policies causing them to black hole their servers for an hour+. On a desktop it might not be so important, in fact a firewall in itself is not as important as on a server. On a server having firewalling is important, and not blocking yourself off from the server is vastly more important then that.

That is exactly what your firewall should do with all traffic that you have not explicitly allowed.

I wasn't talking about a few minutes while troubleshooting. See my first post in this thread where I recommended that the original poster remove all his rules to see if he could connect via SSH. I was talking about the iptables rules that a server runs on a regular day-to-day basis.

Which is why you add an explicit rule to allow SSH connections through, and possibly even restrict that to allow only your IP address (if you have a static IP).

Apart from when you need to flush or re-initialize it. This is a dangerous form of filtering.

but what you suggest would turn a few minutes of what maybe required troubleshooting into a long period blackhole.

Right, and this itself should be handled by a rule, not a policy. If your rules are completed the last rule on the chain should be reject all, there is simply no reasonable reason why you should be relying on a fall back to the policy. However if you need to flush the firewall for whatever reason, you need to be able to get back into the server to reconfigure the firewall, thus there is reasonable reason to have an accept policy, this is why firewalls on a lot, if not most distributions default to this type of set-up.