Bug 153252 - [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"
Summary: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 8.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-17 16:30 UTC by Alexander Verbod
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments
file.diff (2.24 KB, patch)
2010-12-17 16:30 UTC, Alexander Verbod
no flags Details | Diff
ipfw.patch2.txt (1.64 KB, application/octet-stream; charset="utf-8")
2010-12-18 20:00 UTC, UMLLMTHW8EWBC7QMJE.3FZA88RFFWF
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Verbod 2010-12-17 16:30:14 UTC
1. Firewall lock-down system if script "/etc/rc.d/ipfw start" called twice.

2. "sysctl" utility inside "/etc/rc.d/ipfw" script used without full path
   prefix that cause error in case if PATH environment variable contain path
   to current directory "./" and script called from directory "/etc/rc.d"

3. /etc/rc.d/ipfw script always add "/etc/rc.d/natd" to "firewall_coscripts"
   variable regardless if "natd" was enabled in rc.conf or not.

Fix: Attached patch will fix all three issues

Patch attached with submission follows:
How-To-Repeat: Add to "/etc/rc.conf" following strings:

#=====================
firewall_enable='YES'
firewall_type='OPEN'
firewall_logging='YES'
firewall_quiet='NO'

firewall_nat_enable='NO'
natd_enable='NO'
dummynet_enable='NO'
#=====================

then start firewall:
/etc/rc.d/ipfw start

second attempt to run 
/etc/rc.d/ipfw start

will lock-down system
Comment 1 Eugene Grosbein 2010-12-17 20:38:45 UTC
1.

> # check if firewall already running to prevent subsequent start calls

One should not unconditionally disable ability of reloading ipfw rules
using "/etc/rc.d/ipfw start" command. For example, it's used extensively
in my systems and does not lead to "lock-down". One should learn
ipfw(8) manual page including CHECKLIST paragraph and make oneself
familiar with proper ways of reloading ipfw over network.

2. Nice catch. However, that's only one of reasons why it is
very bad habit to have "./" in PATH.

3. Please use "diff -u" to make unified diffs,
they are much easier to read.

Eugene Grosbein
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2010-12-17 22:11:53 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-ipfw

Over to maintainer(s).
Comment 3 UMLLMTHW8EWBC7QMJE.3FZA88RFFWF 2010-12-18 20:00:01 UTC
Eugene Grosbein <eugen@grosbein.pp.ru> wrote:

> One should not unconditionally disable ability of reloading ipfw rules
> using "/etc/rc.d/ipfw start" command.

Patch  doesn't "unconditionally disable ability of reloading ipfw rules"!
Patch disables the ability to run start up script "/etc/rc.d/ipfw"
with "start" command twice that causes lockdown even if type of firewall
is "OPEN".

By the term "reloading" I guess you meant the "restart" command
that's doing stop/start sequence, but not start/start. ;)

> For example, it's used extensively
> in my systems and does not lead to "lock-down".

Eugene, you could do with your systems whatever you want, but here was 
described the bug that appears when used standard, non modified OS.

Did you try all steps described in the "How-To-Repeat" section before replying?


> One should learn ipfw(8) manual page including CHECKLIST paragraph

:) 

Could you check please /etc/rc.firewall for presence of this line
"${fwcmd} add 65000 pass all from any to any"
It's the only one line for "OPEN" firewall's profile.

One who claim to know ipfw(8) manual page should understand this
firewall's rule that unconditionally allow all traffic in both direction for any
type of protocols. But after running "/etc/rc.d/ipfw start" twice all rules are
flashed and only default rule: 
65535 deny ip from any to any
to take affect.


> and make oneself familiar with proper ways of reloading ipfw over
> network.

Did I say somewhere that I don't know "proper ways of reloading ipfw
over network"?
If one like to show of, bug report board isn't a good place to do that.

> 2. Nice catch. 
It isn't a catch, it's a report about bugs.

> However, that's only one of reasons why it is
> very bad habit to have "./" in PATH.

It is a perfectly legal operation that shouldn't cause an error on the OS level.
If one can't use a hummer and broke his finger because of that - it isn't mean
that hummer is a bad tool.

> 3. Please use "diff -u" to make unified diffs,
> they are much easier to read.

I'm agree with you on that but I used official advice
http://www.freebsd.org/doc/en/articles/contributing/contrib-how.html
that says:
"The preferred diff(1) format for submitting patches is the unified 
output format generated by diff -u. 
However, for patches that substantially change a region of code, 
a context output format diff generated by diff -c may be more readable
and thus preferable."

Unified patch attached.
Comment 4 Eugene Grosbein 2010-12-19 14:25:52 UTC
On -9.01.-28163 02:59, Ian Smith wrote:
> On Sat, 18 Dec 2010, Alexander Verbod wrote:
>  >  Eugene Grosbein <eugen@grosbein.pp.ru> wrote:
>  >  
>  >  > One should not unconditionally disable ability of reloading ipfw rules
>  >  > using "/etc/rc.d/ipfw start" command.
>  >  
>  >  Patch à doesn't "unconditionally disable ability of reloading ipfw rules"!

"unconditionally disable ability of reloading ipfw rules using
'/etc/rc.d/ipfw start' command" - will this way of reloading ipfw rules
work with your patch applied? It seems, no.

>  >  Patch disables the ability to run start up script "/etc/rc.d/ipfw"
>  >  with "start" command twice that causes lockdown even if type of firewall
>  >  is "OPEN".

It does not cause lockdown if used in right way, I do this all the time.

>  >  By the term "reloading" I guess you meant the "restart" command
>  >  that's doing stop/start sequence, but not start/start. ;)

Disabling firewall is not an option.
There must be a way to reload rules without passing packets by meantime.
This way now is "/etc/rc.d/ipfw start" command.

>  >  > For example, it's used extensively
>  >  > in my systems and does not lead to "lock-down".
>  >  
>  >  Eugene, you could do with your systems whatever you want, but here was 
>  >  described the bug that appears when used standard, non modified OS.

Of course, with standard OS.

>  >  Did you try all steps described in the "How-To-Repeat" section before replying?

Yes. No problems here.

>  >  > One should learn ipfw(8) manual page including CHECKLIST paragraph
>  >  
>  >  :) 
>  >  
>  >  Could you check please /etc/rc.firewall for presence of this line
>  >  "${fwcmd} add 65000 pass all from any to any"
>  >  It's the only one line for "OPEN" firewall's profile.

Yes.

>  >  One who claim to know ipfw(8) manual page should understand this
>  >  firewall's rule that unconditionally allow all traffic in both direction for any
>  >  type of protocols. But after running "/etc/rc.d/ipfw start" twice all rules are
>  >  flashed and only default rule: 
>  >  65535 deny ip from any to any
>  >  to take affect.

Yes, that's intentional. Then 'allow' rule is loaded again,
if you use the command right way.

> Yes, because you're running /etc/rc.d/ipfw start over the network, which 
> I think disabling the firewall in ipfw_prestart() should fix.  Comments?

I don't think we should disable firewall (creating 'open' window).

>  >  > and make oneself familiar with proper ways of reloading ipfw over
>  >  > network.
>  >  
>  >  Did I say somewhere that I don't know "proper ways of reloading ipfw
>  >  over network"?

Proper way is the way when your system does not lock down.

>  >  > 2. Nice catch. 
>  >  It isn't a catch, it's a report about bugs.
> 
> Try not taking critique too defensively.  Perhaps a language problem; 
> 'nice catch' is a compliment; you caught a bug, it should be ${SYSCTL_W}

Exactly, thanks for clarification.

> There's another part of your patch that Eugene didn't comment on that 
> caught my eye:
> 
> -firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +
> +if checkyesno firewall_nat_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +elif checkyesno natd_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +fi
> 
> Firstly, there's no problem with running /etc/rc.d/natd in any case, as 
> it won't do anything (ie is a NOP) unless natd_enable is set in rc.conf.
> 
> Secondly, having firewall_nat_enable set has no need or use for loading 
> natd, they're quite separate methods of performing NAT.

Nice catch ;-) I've overlooked this.

Eugene Grosbein
Comment 5 Chris St Denis 2010-12-20 17:45:04 UTC
If I understand this problem correctly, the lockdown is caused by the 
ssh session getting killed off between the "${fwcmd} -f flush" and the 
subsequent add rules in rc.firewall (or other user-defined custom script).

If this is the case, couldn't the issue be resolved with a simple patch 
along the lines of this?

--- ipfw.old    2010-12-20 09:41:02.000000000 -0800
+++ ipfw        2010-12-20 09:42:02.000000000 -0800
@@ -43,7 +43,7 @@
         [ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall

         if [ -r "${firewall_script}" ]; then
-               /bin/sh "${firewall_script}" "${_firewall_type}"
+               /usr/bin/nohup /bin/sh "${firewall_script}" 
"${_firewall_type}"
                 echo 'Firewall rules loaded.'
         elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; 
then
                 echo 'Warning: kernel has firewall functionality, but' \


-- 
Chris St Denis
Programmer
SmarttNet (www.smartt.com)
Ph: 604-473-9700 Ext. 200
-------------------------------------------
"Smart Internet Solutions For Businesses"
Comment 6 UMLLMTHW8EWBC7QMJE.3FZA88RFFWF 2010-12-22 15:03:26 UTC
Ian Smith <smithi@nimnet.asn.au> wrote:

> Please treat this as a general discussion of issues, as well as your PR.
> Try not taking critique too defensively.  Perhaps a language problem;

I'd always like to learn from people, but if someone can't see
difference between /sbin/ipfw and /etc/rc.d/ipfw and point wrongly to manual
page of /sbin/ipfw(8) while talking many times about some special secret
'right way' how to run _START UP_ script - I just simply trying to explain
that is wrong in my opinion, so no any defense or aggression :)

Ian Smith <smithi@nimnet.asn.au> wrote:
> There may be a easier solution to this problem than having start fail if 
> the firewall is already enabled .. that is, simply disable the firewall 
> in ipfw_prestart(); it's enabled again in ipfw_poststart() and as you 
> see there, it'd be necessary to test for and disable both IPv4 and IPv6 
> firewalls anyway.

I don't think that using ipfw_prestart()/ipfw_poststart() mechanism is 
a good way to resolve this issue. As Eugene already point it out - it will 
disable firewall for a while that will create window when there will be no 
firewall protection at all.

The simplest way to satisfy everybody is to add on the 
top of "/etc/rc.d/ipfw" and "/etc/rc.firewall" this string:
trap ':' 1 2 5 15;
It will guaranty that script doesn't stop in a middle when 
${fwcmd} -f flush
command will be executed that broke connection anyway but at least 
it will allow to finish apply firewall rules and then will be possible to
relogin again, but I don't think it is a nice solution.

IMHO reloading firewall's rules should be handled by additional command such
as "reload" or similar but not in the "start" action because "start" must mean 
"start" only.
Does anybody can start running again for example without prior stopping?
Start must be start. Official documentation doesn't provide any 
explanation how to handle in a special way some particular _start up_ scripts.
Right way to applying firewall's rules over network explained very well for
/sbin/ipfw but not for /etc/rc.d/ipfw and I believe it is right.

I think it should be kept simple - start up script load initial firewall's
rule and after that one should handle reloading of firewall's rules with
own scripts by calling /sbin/ipfw that is intended exactly to do this kind
of actions.

Running command "start" twice is meaningless. If one want to reload 
firewall's rules with 
/etc/rc.d/ipfw then there should be implemented safe command "reload"
or something else, but I don't think it is a good idea.
/etc/rc.d/ipfw is a mechanism that generally 
control service - enable it or not.
If one need just reload firewall's rules it could be done by running
/etc/rc.firewall script enclosed in guarding script instead of 
"/etc/rc.d/ipfw start", something like this:

/bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"

or simply

/usr/bin/nohup /bin/sh /etc/rc.firewall

in case if /usr already mounted.

Ian Smith <smithi@nimnet.asn.au> wrote:
> One of the reasons that people might want to run 'start' again when it's 
> already running is described in (at least) both of:
I'm sorry, but running twice '/etc/rc.d/ipfw start' isn't solution in that case.
I think the right solution is to fix logical bug and run natd first before 
loading firewall rules instead of running "start" command twice.
(BTW, it's impossible to run '/etc/rc.d/ipfw start' on boot twice,
 so it could be a solution)


Ian Smith <smithi@nimnet.asn.au> wrote:
> Yes, because you're running /etc/rc.d/ipfw start over the network, which 
> I think disabling the firewall in ipfw_prestart() should fix.  Comments?
Well, actually it wasn't me who "running '/etc/rc.d/ipfw start' over 
the network", it was my students who learning to manage FreeBSD. They 
wrote some script that accidentally called twice "/etc/rc.d/ipfw start" and
I explained them that they couldn't be born twice, so the ipfw service 
couldn't be logically started twice too. 


Add code below to /etc/rc.d/ipfw

#--------------
extra_commands='reload'
reload_cmd='ipfw_reload'

ipfw_reload() {
 /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
}
#--------------

add 

#--------------
trap ':' 1 2
#--------------

on top of /etc/rc.d/ipfw and /etc/rc.firewall

and you'll have safe way to reload firewall's rules if you want.

Disabling the firewall in ipfw_prestart() IMHO isn't right.


Ian Smith <smithi@nimnet.asn.au> wrote:
> Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good 
> idea when discussing security, which is what a firewall is all about.
Well, I completely agree with you and Eugene on that if it come to a 
general security. This is kind of topic, but you forget that some 
projects don't need to be opened to the wild internet, it could be an 
automatic stations in closed environment where using ./ in the PATH can 
simplify things a lot without any security issues.
The point is that OS should protected itself from tricks that could be 
done with ./ in the PATH. Providing full path to the programs on an 
OS level is always a good idea.

Ian Smith <smithi@nimnet.asn.au> wrote:
> There's another part of your patch that Eugene didn't comment on that 
> caught my eye:
>
> -firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +
> +if checkyesno firewall_nat_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +elif checkyesno natd_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +fi
>
> Firstly, there's no problem with running /etc/rc.d/natd in any case, as 
> it won't do anything (ie is a NOP) unless natd_enable is set in rc.conf.

If it won't to do anything then why OS need to execute additional useless
operations? 
/etc/rc.d/ipfw is already checked in ipfw_prestart() function
- is nat needed or not, so no any reason to complicate it.
I prefer in source code clear logic - if it isn't needed then it 
shouldn't be run and this logic IMHO should be handled in one 
place to guaranty simplicity and independence. It just a couple of 
strings that wouldn't bloat OS but increase speed of boot process by
excluding useless operations.

Anyway all this code block could be excluded if nat will be loaded 
in ipfw_prestart() function that will fix issue shown in PR's:

http://www.freebsd.org/cgi/query-pr.cgi?pr=153155
http://www.freebsd.org/cgi/query-pr.cgi?pr=148137

and exclude useless operation such as 
firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
in the end of /etc/rc.d/ipfw




Eugene Grosbein <egrosbein@rdtc.ru> wrote:
> "unconditionally disable ability of reloading ipfw rules using
> '/etc/rc.d/ipfw start' command" - will this way of reloading ipfw rules
> work with your patch applied? It seems, no.
Eugene, don't take my words as offense please, lets talk about technical
aspects only.
Do you reload MySql with '/usr/local/etc/rc.d/mysql-server start'?
I guess - no. The same with other services because meaning of word "start"
is to born new instance of something.
"/etc/rc.d/ipfw start" isn't exclusion, it should follow human's logic.
If one want to reload firewall's rules he/she need to implement command "reload".

Eugene Grosbein <egrosbein@rdtc.ru> wrote:
> It does not cause lockdown if used in right way, I do this all the time.
Instead of repeating many times about magic "right way" could you point me
to documentation where is this "right way" explained?
Don't point me to ipfw(8) manual page again please because it describe 
"/sbin/ipfw" but isn't "/etc/rc.d/ipfw".
There is a big difference between them.

I didn't saw in the documentation a special 'right way' of using rc.d start up
scripts. May be I miss something, may be you.
You can execute anyone scripts without any parameters in rc.d directory and it 
will show all available arguments that can be passed to scripts.
I didn't found anyone rc scripts that says it need to be used in a special
"right way".
There no and shouldn't be any special tricks to run start up scripts.



Eugene Grosbein <egrosbein@rdtc.ru> wrote:
> Disabling firewall is not an option.
> There must be a way to reload rules without passing packets by meantime.
> This way now is "/etc/rc.d/ipfw start" command.
Absolutely agree with you on that - "Disabling firewall is not an option" 
but reloading firewall's rules by employ "/etc/rc.d/ipfw start" isn't
an option too. I guess all our disagreement is because there no command 
"reload" for ipfw service.


Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>  >  Did you try all steps described in the "How-To-Repeat" section before replying?
> Yes. No problems here.
I bet you did it from system console or by enclosing "/etc/rc.d/ipfw start"
to surrounding guarding script, otherwise if you don't protect 
'/etc/rc.d/ipfw start' from interruption then first 
"ipfw -f flash" command will broke connection to the box and script
"/etc/rc.d/ipfw" will stop execution in a middle by leaving box inaccessible
over network.


Eugene Grosbein <egrosbein@rdtc.ru> wrote:
> Ian Smith <smithi@nimnet.asn.au> wrote:
> > Firstly, there's no problem with running /etc/rc.d/natd in any case, as 
> > it won't do anything (ie is a NOP) unless natd_enable is set in rc.conf.
> > 
> > Secondly, having firewall_nat_enable set has no need or use for loading 
> > natd, they're quite separate methods of performing NAT.
>
> Nice catch ;-) I've overlooked this.

I don't agree with you guys here. 
There no any reason to execute /etc/rc.d/natd if it will not be used.
Pointless operation. 
You create multiple dependency that is hard to track it down. 
Each script should be independent as much as possible and don't relay
on assumption that /etc/rc.d/natd wouldn't start never.
Why not to handle all logic in one place instead of creating 
possible holes. It just three additional lines that whouldn't bloat OS to the
hell but ensure clear logic of operations and exclude useless running
of /etc/rc.d/natd if it disabled. 
There already exist condition statements in the ipfw_prestart()
function that tried to figure out if nat will be used or not, so IMHO
better to handle it exactly in that place where test condition was done instead of
cheese it up across multiple scripts.
Comment 7 UMLLMTHW8EWBC7QMJE.3FZA88RFFWF 2010-12-22 15:08:01 UTC
Chris St Denis <chris@smartt.com> wrote:
> If I understand this problem correctly, the lockdown is caused by the
> ssh session getting killed off between the "${fwcmd} -f flush" and the
> subsequent add rules in rc.firewall (or other user-defined custom script).

You right, "${fwcmd} -f flush" will broke connection to remote machine and start
up script stop its execution, so no any firewall's rules applied and only 
default 65536 deny rule is in charge.

>
> If this is the case, couldn't the issue be resolved with a simple patch
> along the lines of this?
>
> + /usr/bin/nohup /bin/sh "${firewall_script}"

/usr couldn't be available on start up time, so IMHO it will be better
to use /bin/sh -T .... as I already show it in the previous post.
Comment 8 Eugene Grosbein 2010-12-22 17:07:18 UTC
On 22.12.2010 21:03, Alexander Verbod wrote:
> Ian Smith <smithi@nimnet.asn.au> wrote:
> 
>> Please treat this as a general discussion of issues, as well as your PR.
>> Try not taking critique too defensively.  Perhaps a language problem;
> 
> I'd always like to learn from people, but if someone can't see
> difference between /sbin/ipfw and /etc/rc.d/ipfw and point wrongly to manual
> page of /sbin/ipfw(8) while talking many times about some special secret
> 'right way' how to run _START UP_ script - I just simply trying to explain
> that is wrong in my opinion, so no any defense or aggression :)

No secrets here. You was pointed to section that has second paragraph
leading to /usr/share/examples/ipfw/change_rules.sh.

Examples directory, right? This script shows proper way.

> IMHO reloading firewall's rules should be handled by additional command such
> as "reload" or similar but not in the "start" action because "start" must mean 
> "start" only.
> Does anybody can start running again for example without prior stopping?

Yes. Why not? :-)

> Start must be start. Official documentation doesn't provide any 
> explanation how to handle in a special way some particular _start up_ scripts.
> Right way to applying firewall's rules over network explained very well for
> /sbin/ipfw but not for /etc/rc.d/ipfw and I believe it is right.

/etc/rc.d/ipfw is basically wrapper for /sbin/ipfw, so all rules apply.

> I think it should be kept simple - start up script load initial firewall's
> rule and after that one should handle reloading of firewall's rules with
> own scripts by calling /sbin/ipfw that is intended exactly to do this kind
> of actions.

That's POLA issue. One should not break commands worked for years.
Instead, fix bugs :-) And no, "/sbin/ipfw flush" does NOT break connections.
Really, it does not deal with TCP connections at all.
At application layer, sendto()/send() failure is NOT
a legitimate reason to break session/connection, terminate user session
and cause SIGHUP to be sent to users' processes.

You may use one particular sshd(8) implementation having this misfeature
to maintain the system over network, but it does not mean it's flaws
should bring changes to firewall. You may also use other implementation
possibly not having this bug. This one is in base system - well, that's
another reason to fix bug where it is - inside sshd, but not touch
perfectly working firewall.

> Running command "start" twice is meaningless. If one want to reload 
> firewall's rules with 
> /etc/rc.d/ipfw then there should be implemented safe command "reload"
> or something else, but I don't think it is a good idea.
> /etc/rc.d/ipfw is a mechanism that generally 
> control service - enable it or not.
> If one need just reload firewall's rules it could be done by running
> /etc/rc.firewall script enclosed in guarding script instead of 
> "/etc/rc.d/ipfw start", something like this:
> 
> /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
> 
> or simply
> 
> /usr/bin/nohup /bin/sh /etc/rc.firewall
> 
> in case if /usr already mounted.

That would work for pre-8 versions of FreeBSD but not anymore
because of coscripts. So, running just /etc/rc.firewall
to reload rules is not an option anymore.
Only /etc/rc.d/ipfw start is right way for now.

> Ian Smith <smithi@nimnet.asn.au> wrote:
>> One of the reasons that people might want to run 'start' again when it's 
>> already running is described in (at least) both of:
> I'm sorry, but running twice '/etc/rc.d/ipfw start' isn't solution in that case.
> I think the right solution is to fix logical bug and run natd first before 
> loading firewall rules instead of running "start" command twice.
> (BTW, it's impossible to run '/etc/rc.d/ipfw start' on boot twice,
>  so it could be a solution)

Here we may have a security issue. Firewall should be loaded
before interfaces brought up. natd may depend on interfaces up and running
to initialize itself properly. For example, it may need to know right MTU
of interface (I can describe why it may need it in detail, if you wish).
Basically, it means that firewall should support its own DIVERT rules
configuration before natd is started (and it supports) and it means
that natd should be started later than firewall, not before.
The system behaves this way now and there are reasons for it.

> Ian Smith <smithi@nimnet.asn.au> wrote:
>> Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good 
>> idea when discussing security, which is what a firewall is all about.
> Well, I completely agree with you and Eugene on that if it come to a 
> general security. This is kind of topic, but you forget that some 
> projects don't need to be opened to the wild internet, it could be an 
> automatic stations in closed environment where using ./ in the PATH can 
> simplify things a lot without any security issues.

Just use telnet then :-) it won't break sessions AFAIR.

> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> "unconditionally disable ability of reloading ipfw rules using
>> '/etc/rc.d/ipfw start' command" - will this way of reloading ipfw rules
>> work with your patch applied? It seems, no.
> Eugene, don't take my words as offense please, lets talk about technical
> aspects only.
> Do you reload MySql with '/usr/local/etc/rc.d/mysql-server start'?
> I guess - no. The same with other services because meaning of word "start"
> is to born new instance of something.
> "/etc/rc.d/ipfw start" isn't exclusion, it should follow human's logic.
> If one want to reload firewall's rules he/she need to implement command "reload".

I'm not against implementing "reload". I'm strongly against breaking POLA
and breaking working setups by prohibition of multiple "/sbin/ipfw start" calls
for sake of someone's logic favour. Instead, one could fix real problem with sshd.

> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> It does not cause lockdown if used in right way, I do this all the time.
> Instead of repeating many times about magic "right way" could you point me
> to documentation where is this "right way" explained?

See above.

> Don't point me to ipfw(8) manual page again please because it describe 
> "/sbin/ipfw" but isn't "/etc/rc.d/ipfw".
> There is a big difference between them.

But same rules apply and lead to success :-)

> I didn't saw in the documentation a special 'right way' of using rc.d start up
> scripts. May be I miss something, may be you.

Well, you may consider documentation insufficient (I do not :)
Then, feel free to submit patches for documentation but please,
don't fix what ain't broken.

> You can execute anyone scripts without any parameters in rc.d directory and it 
> will show all available arguments that can be passed to scripts.
> I didn't found anyone rc scripts that says it need to be used in a special
> "right way".
> There no and shouldn't be any special tricks to run start up scripts.

There may be any kind of tricks depending on real task
(all "tricks" should be documented, though), for example:

- one should not blindly call rc.d script for natd with "restart" argument
over NAT'ed connection, because THAT may really break TCP connection;
- one should not blindly call rc.d script for routed with "restart" argument
when it may destroy route it's using for pretty long time (RIP diverges slowly);
- one should not blindly call rc.d script for amd/nfsd with "restart" argument
when it's current directory resides on network-mounted file system;
- et cetera, et cetera, et cetera (ipsec, netif, ...)

> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> Disabling firewall is not an option.
>> There must be a way to reload rules without passing packets by meantime.
>> This way now is "/etc/rc.d/ipfw start" command.
> Absolutely agree with you on that - "Disabling firewall is not an option" 
> but reloading firewall's rules by employ "/etc/rc.d/ipfw start" isn't
> an option too.

Why not? It works when used right way, and worked for long time.

> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>>  >  Did you try all steps described in the "How-To-Repeat" section before replying?
>> Yes. No problems here.
> I bet you did it from system console or by enclosing "/etc/rc.d/ipfw start"
> to surrounding guarding script, otherwise if you don't protect 
> '/etc/rc.d/ipfw start' from interruption then first 
> "ipfw -f flash" command will broke connection to the box and script
> "/etc/rc.d/ipfw" will stop execution in a middle by leaving box inaccessible
> over network.

My first letter was written in reply to your PR having no words
about running command over network. Or about what your "lock-down" means,
kernel panic? kernel hang? shell process deadlock? I've seen so many
weird effects with FreeBSD over time, so avoid attempts to use telepathy.

Now you know how important it is to be exact in problem reports.

And yes, I generally use screen(1) for remote sessions,
so my connections do not break. And I always use output redirection
for "/etc/rc.d/ipfw start" even for screen-based sessions.
That's the safe and working way.

Eugene Grosbein
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:00 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped