Re: *_enable="YES" behavior is bogus

[M. Warner Losh]

In message: 
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

Re: *_enable="YES" behavior is bogus

[Garance A Drosihn]

At 4:52 PM -0500 2/1/02, Garance A Drosihn wrote:
>It *is* reasonable for them to assume the same
>behavior would be true for network_enable=no.

I meant "firewall_enable=no" here!   If the option *was* called
"network_enable=no", then it would be VERY reasonable to expect
the machine to be locked-down!   :-)

[it wouldn't surprise me if I have done that in some other messages,
too.  Sorry about that.  Maybe I should check to see if my own
brain's ethernet cable is plugged in]

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

RE: *_enable="YES" behavior is bogus

[Garance A Drosihn]

At 5:16 PM -0500 2/1/02, Benjamin P. Grubin wrote:
>  > 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.

Well, actually, I can easily think of reasons a person might end
up with the firewall compiled into the kernel, and why they might
really want to come up in a completely-locked down environment.
That may seem odd, but sometimes there are good reasons to be
"very paranoid".

I can also see that there should be some knob in rc.conf so a
person can easily trigger this behavior.  Note that they might
want to do this *after* the initial install, where they have some
reason where they want to reboot and immediately come up with
the firewall blocking all network access.  I really do not want
to attack the intelligence of either group of users, since both
groups have understandable reasons (IMO) for wanting the behavior
that they want.  Sometimes that happens.

I just do not believe that the knob for this lockdown mode should
be called 'firewall_enable=no', given the practical reality of
what a user sees when they set 'foo_enable=no' for all other
values of 'foo'.

[and it turned out that the panic call I got in the middle of my
previous message was due to a loose ethernet cable, and not a
bunch of servers crashing, so that turned out to be easy... :-)]

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

RE: *_enable="YES" behavior is bogus

[Benjamin P. Grubin]

Hello,

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

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On Behalf Of 
> Garance A Drosihn
> Sent: Friday, February 01, 2002 4:52 PM
> To: Erik Trulsson; Paul Fardy
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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
consistency.

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

Cheers,
Ben



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

Re: *_enable="YES" behavior is bogus

[Garance A Drosihn]

At 6:36 PM +0100 2/1/02, Erik Trulsson wrote:
>Consider that the actual code in the various rc* start scripts is
>in most cases of the form:
>
>if foo_enable==yes
>   do stuff
>else
>   do nothing

Let me approach this from a different angle.  Several people have
tried to argue this by proposing various "What if?" scenarios.
Let me also do that.

Let us say that we did happen to decide that for all 'foo_enable'
options in rc.conf, a setting of 'foo_enable=no' does in fact
mean that the service 'foo' will NOT be running at the end of
the boot-up process.  Maybe some company offers us a million
dollars if we will just guarantee that, and we think of all the
good programmers we could pay for that million dollars, so we
all agree to standardize on this definition of 'enable=no'

If we decided to do that, then as a *practical* matter, how many
of the current options in rc.conf would need to be changed?  I
don't mean "if we need to cover the case where someone renames
/usr/sbin/lpd to /bin/echo, what would we need to do?".  I mean,
given any default installation of the base operating system (no
ports), and any valid kernel configuration, in what cases of
'enable' would we really *have* to add some lines to those 'else'
clauses that you quoted?

In the case of lpd_enable, as a *practical* matter, there would be
no need to write additional code.  There is no kernel setting which
automatically turns on lpd support, and if 'lpd_enable=yes' does
not *start* /usr/sbin/lpd, then we do know that the lpd program is
not running.

I don't have time to look into it now, but I expect that is true for
all of the other 'enable' options.  As a *practical* reality, I expect
that the firewall_enable option is the only one where we do need to
write code to implement the 'enable=no' case as I described it.

People will argue that "this is special, because it's a kernel option!
Lpd would behave exactly the same way, *if* it were a kernel option!".
All fine and good, *if* it were true, but irrelevant to my "What if?"
question.  Of the current foo_enable options, which options would we
need to change *right now* to support the definition of 'enable=no'
that some people think is logical?

[mind you, I don't actually know the answer to that question, but I
just got a phone call and need to leave right now...  So, I am
breaking the first rule of a good lawyer, in that I am asking a
question that I don't already know the answer to.  :-)   ]

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

Re: *_enable="YES" behavior is bogus

[Garance A Drosihn]

At 6:36 PM +0100 2/1/02, Erik Trulsson wrote:
>Consider that the actual code in the various rc* start scripts is
>in most cases of the form:
>
>if foo_enable==yes
>   do stuff
>else
>   do nothing

The RC scripts are starting up in a "known" environment (loosely
speaking).  Enough is known about that environment that the code
in question knows there there is no need to do anything to turn
off the service if the rc.conf file has blah_enable=NO.  When
'lpd_enable=no', for instance, then it is very reasonable for
the startup scripts to assume that absolutely nothing needs to
be done to turn off lpd.  We pretty much "know" it ain't running,
so why write code to turn it off?

I imagine it's futile to argue this, if you're going to argue it
based on the implementation-details in rc.conf, instead of asking
"what should we do?" from the point of view of what would make
the most sense to the most users.

As a support person, I also like to think of another question.
Given that some users will get it "wrong" no matter which way
we do this, then which "wrong" is the one that we can handle
the most gracefully?

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.

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

But I think the second "error" is also very bad, and there is no
way for us to address it via coding.  It might be a pretty major
hassle for that person to fix the problem (particularly if they
did this over a remote connection, and the machine is far away).

And yes, the user should be brilliant and a complete expert before
they change any setting in any file on a unix box, but hearing that
"they were stupid" is not much of a soothing consolation to the user
when they are hit with a situation like this.  As a support person,
it is pretty rare that the user is happy when they find out "they
were stupid" for making a perfectly reasonable assumption, based on
how everything else in rc.conf seems (to them) to work.  No, they
did not read the code to see what the 'else' case of every "enable"
option does, but they did notice that every time they set
"blah_enable=no", they found that when the system came up "blah"
was not running.  It *is* reasonable for them to assume the same
behavior would be true for network_enable=no.

I understand the reasoning of people who think the present behavior
is logical.  However, we can write code which helps those people if
we pick what seems (to them) to be the illogical behavior.  We do
not have that option for the group of people who happen to use a
different set of logical reasoning to come to the opposite conclusion.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

Re: *_enable="YES" behavior is bogus

[Siegbert Baude]

Hi all,

> But I think that the intent in /etc/rc.conf is that enable="NO"
> _is_ the same thing as disabling it. You might say "If that were
> the intent, they'd have used ___." What word should we use
> to  indicate the absolute YES or NO that some of us believe
> should be the simple correct interpretation?

I would suggest "foo_functionality". That is very clear, (albeit a bit long
*g*).


Ciao
Siegbert


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

Re: *_enable="YES" behavior is bogus

[Erik Trulsson]

On Fri, Feb 01, 2002 at 02:47:30AM -0330, Paul Fardy wrote:

> These examples, _and_yours_, are examples that suggest that
> /etc/rc.conf has a fundamental principle that
> 
>   foo_enable="YES/NO"
> 
> is supreme. One can set up all the requisite parameters (e.g. you
> can create sendmail.cf, named.conf, tune inetd.conf, compile psm
> into the kernel or install any of various screen savers), yet one
> can still set an appropriate variable
> 
>   foo_enable="NO"
> 
> which will not enable the feature.

It will not enable it, no. Nor will the feature be disabled if it for
some reason already was enabled.


> 
> >Not enabling something is *not* the same thing as disabling it.
> 
> But I think that the intent in /etc/rc.conf is that enable="NO"
> _is_ the same thing as disabling it. You might say "If that were


Consider that the actual code in the various rc* start scripts is
in most cases of the form:

if foo_enable==yes
  do stuff
else
  do nothing


Some cases are instead

if foo_enable==no
  do nothing
else
  do stuff



A cursory search found a total of one instance where foobar="NO" actually
makes something happen, and it was not of the form foo_enable="NO"

(The single exception I found is
tcp_extensions="NO")


For all other variables one can set in rc.conf foobar="NO" means
"do nothing".


Looking at the code the intent certainly seems to be foo_enable="NO"
shouldn't do anything.




> the intent, they'd have used ___." What word should we use
> to  indicate the absolute YES or NO that some of us believe
> should be the simple correct interpretation?

foo_enabled="YES/NO"  perhaps??

I.e. describing the desired state of the feature instead of the desired
action to be taken.


There are of course several people who feel that the current behaviour
is the intuitive and obviously correct interpretation and would prefer
not to have it changed.


-- 

Erik Trulsson
[EMAIL PROTECTED]

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

Re: *_enable="YES" behavior is bogus

[Paul Fardy]

Paul Fardy <[EMAIL PROTECTED]> types:
>> When the rc.conf file includes
>>  foo_enable="NO"
>> it's right to expect that the system will operate like a system that does
>> not
>> have foo installed.

On Thursday, January 31, 2002, at 04:43  AM, Mike Meyer wrote:
> So you think that if I install a syslog from ports that's started via
> /usr/local/etc/rc.d/syslogd.sh, "syslog_enable=NO" in /etc/rc.conf
> should disable it?  For that matter, if I set ipfilter_enable="YES" and
> firewall_enable="NO", should the system enable ipfilter or not, as
> there are two contradictory things.

These aren't similar situations.

Your syslog example is essentially an issue of scope or name space
and not the meaning "enable" or of "no".  It's my understanding
that the values in /etc/rc.conf apply to the FreeBSD core and not
to any version that someone might install to override the core
version.  The configuration for an package that sits in /usr/local
should be found in /usr/local/etc.  I'd be disappointed to see
packages that don't follow such a policy.

There are many examples in rc.conf similar to your suggested
contradiction:

natd_enable="NO"
natd_interface="fxp0"
inetd_enable="NO"
inetd_program="/usr/sbin/inetd"

These examples, _and_yours_, are examples that suggest that
/etc/rc.conf has a fundamental principle that

foo_enable="YES/NO"

is supreme. One can set up all the requisite parameters (e.g. you
can create sendmail.cf, named.conf, tune inetd.conf, compile psm
into the kernel or install any of various screen savers), yet one
can still set an appropriate variable

foo_enable="NO"

which will not enable the feature.

> Not enabling something is *not* the same thing as disabling it.

But I think that the intent in /etc/rc.conf is that enable="NO"
_is_ the same thing as disabling it. You might say "If that were
the intent, they'd have used ___." What word should we use
to  indicate the absolute YES or NO that some of us believe
should be the simple correct interpretation?

Paul Fardy


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