Which would you rather have, /sbin/iptables that is setuid and user-executable (which nobody advocated, for good reason) or my line in sudoers? Same thing goes for scripts you write yourself.

Actually those two choices are quite similar (control access to iptables via file permissions or control access via sudoers). I would have neither. I must stress again that the line you suggested for inclusion in sudoers lets you run any iptables command you want (in other words: run iptables with any arguments you want) as long as you are user nobody. Since on the OP's system nobody is the web server account, lots of code runs as that user and will have access to run iptables. Indeed on mostly any system there's usually some piece of code that runs as user nobody that should not be trusted with iptables privileges.

Obviously the goal is for unprivileged users to be able to cause iptables commands to be executed, but the goal is to only permit those iptables commands that the application specifically requires. Which iptables commands get executed is only under the indirect control of the user, according to what the CGI script will choose to honour. That's why the limited API between the client's user agent and the CGI needs to be the where the barrier between security domains is located (or equivalently, the CGI can call a backend that provides an API that is not more powerful than the one facing the user agent; some other monks suggested that).

All of this of course assumes that the CGI actually limits what the end user can cause iptables to do. If the CGI script is the following code, then all bets are off!

use CGI qw/standard/;
system("iptables " . param("iptables_command"));
[download]