In message: <email@example.com> Garance A Drosihn <[EMAIL PROTECTED]> writes: : In this discussion, there have been two suggestions as to how : 'firewall_enable=no' should behave. : 1) if the firewall is compiled in the kernel, then "=no" : means that the firewall is blocking all packets, no : matter what other rules might be lying around. The : machine is completely locked down from network access : (ie, the present behavior). : or 2) no matter how the kernel is compiled, "=no" means the : machine acts as if there is no firewall installed. Ie, : it accepts all packets. No packets are blocked. The : machine is wide open. : : If the user *expects* 1, but we actually implement 2, then the : machine is wide-open when they did not expect that. My position : is that we can *easily* do something to help that person : immediately realize that they did not get what they expected. : : If the user *expects* 2, but we implemented 1, then the machine : is locked down. If the user is not sitting at the console of : the machine, then there is absolutely nothing which can be done : (from a coding perspective) to help that person out. They must : have a keyboard and monitor on that machine, and they must go : to the machine and login via that console.
The rational for #1 being implemented now is that all security features, when specially enabled (which you had to do to compile the kernel with ipfw in it) must fail "safely." Safely is defined as being more restrictive than less. #2 is less. That's the whole reason we do this. But I think this is going to be one of those threads that lasts forever and then nothing happens because they end in deadlock. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message