From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 17:10:13 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C0E11065693 for ; Wed, 22 Dec 2010 17:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D36658FC1B for ; Wed, 22 Dec 2010 17:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMHACEf082156 for ; Wed, 22 Dec 2010 17:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMHACCD082155; Wed, 22 Dec 2010 17:10:12 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 17:10:12 GMT Message-Id: <201012221710.oBMHACCD082155@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Eugene Grosbein Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Grosbein List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:10:13 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: Eugene Grosbein To: Alexander Verbod Cc: bug-followup@freebsd.org, freebsd-ipfw@freebsd.org, Ian Smith Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Wed, 22 Dec 2010 23:07:18 +0600 On 22.12.2010 21:03, Alexander Verbod wrote: > Ian Smith 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 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 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 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 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 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 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