I'm usually but a lurker, though I'd like to toss in my $.02 on this...

> -----Original Message-----
> [mailto:[EMAIL PROTECTED]] On Behalf Of 
> Garance A Drosihn
> Sent: Friday, February 01, 2002 4:52 PM
> To: Erik Trulsson; Paul Fardy
> Subject: Re: *_enable="YES" behavior is bogus

> 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.

It strikes me that #2 is the clear winner in terms of implementation

> I understand the first "error" (where the machine ends up completely
> open) is not desirable.  It is very very bad.  However, I 
> think we can write some code to help out that user.  That 
> user is extremely likely to be sitting at the console, and 
> they are extremely likely to want to log into that console, 
> and there is nothing which prevents them from logging in.  We 
> can provide warning messages for that user, and they can 
> immediately fix the "error".

I'm not sure why this would be considered not desirable or "bad" in any
other way.  When the kernel is first compiled with the firewalling code,
it seem silly that anyone would, at that early point, consider
themselves firewalled.  Even your average knucklehead user that wants to
use the firewalling code, and compiles a new kernel with it present
(implying at least some level of technical proficiency in the first
place) would not expect to render the network useless--or be
protected--until some chain of events occurred.  The proper thing (IMHO)
is to leave the behavior of the box unchanged (unfirewalled) until a
change is willfully implemented--as opposed to some functionality being
added to the kernel, which should not really effect normal operations
(obviously with some rather large exceptions).  If the exceptions are a
concern, it seems to me focus should be on the consistency of kernel
configuration and how it relates to normal operations--not the rc files.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to