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
