In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : Here's a new patch. But there isn't much of a point if we do not : also disallow ipfw DELETE and FLUSH. And the pipe config commands : as well as anything else that changes the firewall state. Firewalls : are there to protect the systems behind them. I think deleting the : rule that, say, prevents spoofing is as bad as adding a rule that : allows everything through :-(
This comment got me thinking. The thinking lead to a lot of looking at code between compiles today, and more this evening. It would appear that the test that was there was sufficient to deal with the cases that I was worried about. Revisiting the change: - if (sopt->sopt_name == IP_FW_ADD || + if (sopt->sopt_name == IP_FW_ADD || sopt->sopt_name == IP_FW_UNBREAK || (sopt->sopt_dir == SOPT_SET && sopt->sopt_name != IP_FW_RESETLOG)) { Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET requests. Since GET + ADD is only case that isn't a SET that changes things, the == SOPT_SET takes care of the case that you added. For a while I thought one could do nasty things based on GET + FLUSH, say, but in raw_ip.c, we do the proper checks before calling ip_fw_ctl_ptr(). So it looks like this code is subtle enough to have fooled both of us. This one change isn't needed for this patch. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message