Date: Fri, 01 Feb 2002 22:42:19 -0700 (MST) From: "M. Warner Losh" <imp@village.org> To: drosih@rpi.edu Cc: current@FreeBSD.ORG Subject: Re: *_enable="YES" behavior is bogus Message-ID: <20020201.224219.62370052.imp@village.org> In-Reply-To: <p05101415b880b7928804@[128.113.24.47]> References: <5F46C986-16DB-11D6-8CEC-00039359034A@mac.com> <20020201173641.GA48397@student.uu.se> <p05101415b880b7928804@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <p05101415b880b7928804@[128.113.24.47]>
Garance A Drosihn <drosih@rpi.edu> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020201.224219.62370052.imp>