Re: ipfw userland breaks again.
[EMAIL PROTECTED] wrote, On 12/14/02 23:13: I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable at module load time using a kernel environment variable. Looks to me that it would do what you want. Should we think about kldload logic change ? Loading modules giving them a parameter string parsed on MOD_LOAD event seems to be most generic way to do the things (not only with ipfw) ... The syscall allow arbitrary string as parameter, so it's not limited to filename only, event routine declaration already has the void *data variable, so the necesarry changes doesn't hit the userland (kldload) nor modules code (unless they decide to parse the parameters). Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Huh. Interesting. The IP_FW_ADD test threw me but now that I
look at the code more closely it is only there because IP_FW_ADD
is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends
are SOPT_SET only. Now I see how it works :-)
-Matt
:..
:: rule that, say, prevents spoofing is as bad as adding a rule that
:: allows everything through :-(
:
:This comment got me thinking. The thinking lead to a lot of looking
:at code between compiles today, and more this evening. It would
:appear that the test that was there was sufficient to deal with the
:cases that I was worried about. Revisiting the change:
:
:- if (sopt-sopt_name == IP_FW_ADD ||
:+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
: (sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
:
:Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
:SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
:requests. Since GET + ADD is only case that isn't a SET that changes
:things, the == SOPT_SET takes care of the case that you added.
:
:For a while I thought one could do nasty things based on GET + FLUSH,
:say, but in raw_ip.c, we do the proper checks before calling
:ip_fw_ctl_ptr().
:
:So it looks like this code is subtle enough to have fooled both of
:us. This one change isn't needed for this patch.
:
:Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Tue, Dec 17, 2002 at 10:23:15AM -0800, Matthew Dillon wrote: Huh. Interesting. The IP_FW_ADD test threw me but now that I look at the code more closely it is only there because IP_FW_ADD is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends are SOPT_SET only. Now I see how it works :-) ``cvs log -r1.145 -r1.147 ip_fw.c'' for more details. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48927/pgp0.pgp Description: PGP signature
Re: ipfw userland breaks again.
On Sun, Dec 15, 2002 at 08:47:23PM +, Nik Clayton wrote: On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote: : ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. Really? You think I should learn to play well with others? You think it's appropriate to request that I spend a man week rewriting an API? You really do? You think it's appropriate to bring up a bogus security issue when its obvious that no security issue exists, abusing your power in that manner is playing well with others? This is Warner of core? I think it's more appropriate if you put options IPFIREWALL_DEFAULT_TO_ACCEPT on any boxes where you're running test code. That's much more acceptable than committing a kludge with a poor choice of name after minimal discussion when efforts would be better spent working on other rough edges in the run up to 5-release. There were times, even within RELENG_4 lifecycle, when IPFW ABI was broken, making it really hard to remotely upgrade IPFW boxes, as we're required to boot with the new kernel before doing an installworld. It once costed me about 12 hours of downtime of our Australian production box. This is from the -STABLE's UPDATING: 20010109: ipfw interface changed. Make sure that the userland and kernel match or you won't have the firewall rules you think you do. 19990620: IPFW uid/gid-based filtering support has been committed. This breaks binary compatibility with previous copies of ipfw(8). Any utilities using the ioctl()s of ipfw (especially ipfw(8)) need to be recompiled with the newest headers installed. 19980725: The ipfw interface to the kernel has changed. You will need to recompile ipfw programs for the new kernel. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48844/pgp0.pgp Description: PGP signature
Re: ipfw userland breaks again.
On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: : :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: : then, as usual, IPFW with the new kernel and : old world fails utterly and now the fragging machine can't access the : :Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. Matt, How this could be helpful in a remote upgrade scenario that has IPFW ABI incompatibility issues? One alternative approach would be to not compile IPFW into a kernel but rather have it loaded as a module. Then, you install new kernel, edit out ipfw_enable=YES for the time being, reboot with the new kernel, installworld, edit ipfw_enable=YES back in, reboot, and you're done. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48845/pgp0.pgp Description: PGP signature
Re: ipfw userland breaks again.
On Mon, 16 Dec 2002, Ruslan Ermilov wrote: On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: : :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: : then, as usual, IPFW with the new kernel and : old world fails utterly and now the fragging machine can't access the : :Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. Matt, How this could be helpful in a remote upgrade scenario that has IPFW ABI incompatibility issues? One alternative approach would be to not compile IPFW into a kernel but rather have it loaded as a module. Then, you install new kernel, edit out ipfw_enable=YES for the time being, reboot with the new kernel, installworld, edit ipfw_enable=YES back in, reboot, and you're done. I think having ipfw as a module doesn't get you fwd or divert. (I may be wrong) Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:How this could be helpful in a remote upgrade scenario that has :IPFW ABI incompatibility issues? : :One alternative approach would be to not compile IPFW into a :kernel but rather have it loaded as a module. Then, you :install new kernel, edit out ipfw_enable=3DYES for the time :being, reboot with the new kernel, installworld, edit :ipfw_enable=3DYES back in, reboot, and you're done. : : :Cheers, :--=20 :Ruslan Ermilov Sysadmin and DBA, Well, the basic problem is that you don't actually know when the IPFW API is going to break. I do incremental upgrades most of the time and IPFW breaks maybe once every 5 upgrades. So for a manual upgrade it can be a severe inconvenience to have to deal with the possibility every time you upgrade. For an automated upgrade one can always automate and 'ipfw unbreak' (or 'ipfw open' as John just suggested to me) is not needed. What this patch does is allow you to upgrade via a serial console normally, without having to pay particular attention to IPFW, and if the IPFW API happens to break you can then simply 'ipfw unbreak' to get access to the network and then fix whatever broke. The only viable alternative that I've heard so far on the lists, other then 'Matt should rewrite the API so it doesn't break' is to have the installkernel and installworld targets check for ipfw incompatibility and install the new ipfw. Of course, this doesn't help if you have to revert the kernel. I still prefer the failsafe my solution supplies. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: Here's a new patch. But there isn't much of a point if we do not
: also disallow ipfw DELETE and FLUSH. And the pipe config commands
: as well as anything else that changes the firewall state. Firewalls
: are there to protect the systems behind them. I think deleting the
: rule that, say, prevents spoofing is as bad as adding a rule that
: allows everything through :-(
This comment got me thinking. The thinking lead to a lot of looking
at code between compiles today, and more this evening. It would
appear that the test that was there was sufficient to deal with the
cases that I was worried about. Revisiting the change:
- if (sopt-sopt_name == IP_FW_ADD ||
+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
requests. Since GET + ADD is only case that isn't a SET that changes
things, the == SOPT_SET takes care of the case that you added.
For a while I thought one could do nasty things based on GET + FLUSH,
say, but in raw_ip.c, we do the proper checks before calling
ip_fw_ctl_ptr().
So it looks like this code is subtle enough to have fooled both of
us. This one change isn't needed for this patch.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : :I disagree with committing this hack; keep it as a local mod if you must. : : : :As to the problem; don't wait for Luigi to fix the ABI problems, do it : :yourself. Good things happen when folks are PO'd and won't settle for the : :status quo. : : : :Sam : : I'm sorry you disagree, but it doesn't change my position. I am not : in the business of rewriting other people's APIs. If it means so much : to you, YOU go and fix it. No? Then don't complain about my fix. It's : no skin off your nose and it will prevent a lot of future headaches, : especially if the RC system makes it nice and friendly. I don't like the patch from a security standpoint. It makes it to easy to turn off a firewall. If you want to be that stupid about security, you should just make the default be 'accept all' and be done with it. I'm opposed to this patch unless you can get the security officer to sign off on it. The defaults are there for a reason so that we fail 'safe' from a security point of view. The real fix is to fix the abi problems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:I don't like the patch from a security standpoint. It makes it to :easy to turn off a firewall. If you want to be that stupid about :security, you should just make the default be 'accept all' and be done :with it. I'm opposed to this patch unless you can get the security :officer to sign off on it. The defaults are there for a reason so :that we fail 'safe' from a security point of view. : :The real fix is to fix the abi problems. : :Warner This is complete BULLSHIT, Warner. This patch exists precisely so the firewall can be turned on in secure mode. It does not make it any easier to turn off then adding a rule: ipfw add 2 allow all from any to any So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :The real fix is to fix the abi problems. : :Warner Doh!!Thanks for volunteering to fix the ABI problems. No? You don't want to do it? Gee, I saw that one coming a mile away! THEN DON'T COMPLAIN. This is not a fucking security issue. This is a patch that solves a major irritation, nothing more, nothing less, except some people can't stand an 8-line fix to the problem apparently. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Hi, On Sun, Dec 15, 2002 at 10:26:22AM -0800, Matthew Dillon wrote: This is complete BULLSHIT, Warner. This patch exists precisely so the firewall can be turned on in secure mode. It does not make it any easier to turn off then adding a rule: ipfw add 2 allow all from any to any So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. How about sending the patch to the Technical Review Board, trb@ instead. Thanks. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:How about sending the patch to the Technical Review Board, trb@ instead. : :Thanks. : :Cheers, : :-- :Anders. Getting bored sitting on your buns? It's already gone to core and, frankly, I think core is the proper forum now that Warner has declared it a security issue (when it obviously isn't. How easy is it to do an ipfw add 2 allow all from any to any? It's ludicrous to call it a security issue). I really don't mind people disagreeing, but I do mind it when people believe that the proper solution is for Matt Dillon to spend a man week fixing a major API that he didn't write instead of comitting an 8 line patch that deals with the issue well enough so sysads don't have to pull their hair out every time it happens. As I said before, I have no problem with the patch being removed once the API is fixed, but I am NOT the guy who should be rewriting the API and, frankly, it is inappropriate for anyone to suggest that I should be if they themselves are not willing to sit down in front of a keyboard and come up with a committable solution of their own. So far all I've heard are utterly trivial complaints from people who aren't willing to code up a solution themselves. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 10:26:22 -0800 (PST) Matthew Dillon [EMAIL PROTECTED] wrote: Hi, must...resist... So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. No, Warner has a point, that patch is simply bandaid (albeit a good one). Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. I know I'm gonna get flamed for this, but you know what's ridiculous? All the flamage you've brought up on the issue. You're a great hacker Matt, just keep it easy and don't take it so personal. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Of course it runs NetBSD! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:This is complete BULLSHIT, Warner. Your attitude it totally unacceptible. Learn to play well with others, or get the fuck out of the project. I am *NOT* blocking you. I'm telling you you need to get the SO's sign off to make sure that there isn't a security issue because the current defaults were set by the so. If you don't like that, then I suggest that you get over yourself and find someplace else to play. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : : : :The real fix is to fix the abi problems. : : : :Warner : : Doh!!Thanks for volunteering to fix the ABI problems. No? You : don't want to do it? Gee, I saw that one coming a mile away! : THEN DON'T COMPLAIN. GET OVER YOURSELF. YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL TOLERATE THIS BULLSHIT ANYMORE. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :In message: [EMAIL PROTECTED] :Matthew Dillon [EMAIL PROTECTED] writes: :: : :: :The real fix is to fix the abi problems. :: : :: :Warner :: :: Doh!!Thanks for volunteering to fix the ABI problems. No? You :: don't want to do it? Gee, I saw that one coming a mile away! :: THEN DON'T COMPLAIN. : :GET OVER YOURSELF. YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL :TOLERATE THIS BULLSHIT ANYMORE. : :Warner Bullshit is exactly what it is Warner, but I'm not the one spouting it. When all is said and done, this patch is utterly trivial and doesn't hurt anyone. I have said on multiple occassions that it can be removed when the API is fixed, but I am not willing to wait for the API to be fixed because the API has been an open issue for, what, a year now? More? If you want to fix the API then you should go and fix it. I should have just comitted the damn thing rather then ask for a review on the mailing list. I should know better by now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. : :I am *NOT* blocking you. I'm telling you you need to get the SO's :sign off to make sure that there isn't a security issue because the :current defaults were set by the so. If you don't like that, then I :suggest that you get over yourself and find someplace else to play. : :Warner This is not a security issue. Why do you think it is? How is 'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'? (Other then the fact that unbreak is immune from API changes). Have you even bothered to read the patch? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. Really? You think I should learn to play well with others? You think it's appropriate to request that I spend a man week rewriting an API? You really do? You think it's appropriate to bring up a bogus security issue when its obvious that no security issue exists, abusing your power in that manner is playing well with others? This is Warner of core? When people say and do reasonable things I am a reasonable guy. When people say and do unreasonable things then I fight tooth and nail. It's that simple. If you don't like it, then tough. There is nothing unreasonable about this patch. NOTHING. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
:
: :
: ::This is complete BULLSHIT, Warner.
: :
: :Your attitude it totally unacceptible. Learn to play well with
: :others, or get the fuck out of the project.
: :
: :I am *NOT* blocking you. I'm telling you you need to get the SO's
: :sign off to make sure that there isn't a security issue because the
: :current defaults were set by the so. If you don't like that, then I
: :suggest that you get over yourself and find someplace else to play.
: :
: :Warner
:
: This is not a security issue. Why do you think it is? How is
: 'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'?
: (Other then the fact that unbreak is immune from API changes).
:
: Have you even bothered to read the patch?
Yes, I have. It potentially has security implications because it is a
security part of the system. That's why I think it would be valuable
to get the SO's input on what you are doing. I've read the patch. It
makes it possible with one ioctl to turn off the firewall to allow you
to use the system. That needs careful reviewed.
In fact, it has one flaw. You'll find on lines
/*
* Disallow modifications in really-really secure mode, but still allow
* the logging counters to be reset.
*/
if (sopt-sopt_name == IP_FW_ADD ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
if (error)
return (error);
#else /* FreeBSD 4.x */
if (securelevel = 3)
return (EPERM);
#endif
}
which you haven't changed. This strikes me as a danger operation to
allow in high security mode, so there likely needs to be some changes
assocaited with the above lines (like an || sopt-sopt_name ==
IP_FW_UNBREAK in the above). Otherwise, an attacker would be able to
turn off the ipfw stuff at a high security level.
I'm not trying to get in your way Matt, I'm just saying that there
needs to be a little discussion on this kludge if you aren't going to
fix the real, underlying problem, ok?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : When people say and do reasonable things I am a reasonable guy. When : people say and do unreasonable things then I fight tooth and nail. : It's that simple. If you don't like it, then tough. There is nothing : unreasonable about this patch. NOTHING. I've answered this in other email, but you need to expand the check at the top of ipfw_ctl to include this new message as one of the ones that is disallowed at high security levels. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Matthew Dillon wrote: [ useless drivel removed ] There's still a TODO list for 5.0. It was even mailed out to developers@ this morning. If you have time to spare in your day, please focus your attention to that right now. Also, fixing the ipfw2 abi is probably a good item to put on the list for getting 5.x to 5-STABLE. Please don't waste time with band-aids that will make people forget that ipfw2 needs attention. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:Also, fixing the ipfw2 abi is probably a good item to put on the list :for getting 5.x to 5-STABLE. Please don't waste time with band-aids :that will make people forget that ipfw2 needs attention. : :Scott This is a reasonable line of argument but my opinion is that it hasn't been fixed for a long time now and unless someone decides they really want to tackle the issue soon it isn't going to be fixed for a long time to come, and we shouldn't continue to create a major hassle for developers and sysads that hit up against the issue. I mean, hey, if someone asked me to rename the command from 'ipfw unbreak' to 'ipfw somelonggobblygookthatyouhavetocutandpaste' I'm willing to do that too :-) But we need either the API fixed or this hack and, right now, the only person willing to do anything is me and my buddy Hack. If someone stood up and said I will take on fixing the API but it will take a month then that's fine with me, I would not feel that I would have to commit this now. But so far nobody has stood up and said that. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon [EMAIL PROTECTED] said: Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. All the better, if you refuse to be civil to your fellow developers. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:I've answered this in other email, but you need to expand the check at
:the top of ipfw_ctl to include this new message as one of the ones
:that is disallowed at high security levels.
:
:Warner
Here's a new patch. But there isn't much of a point if we do not
also disallow ipfw DELETE and FLUSH. And the pipe config commands
as well as anything else that changes the firewall state. Firewalls
are there to protect the systems behind them. I think deleting the
rule that, say, prevents spoofing is as bad as adding a rule that
allows everything through :-(
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: sbin/ipfw/ipfw.8
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.116
diff -u -r1.116 ipfw.8
--- sbin/ipfw/ipfw.826 Nov 2002 19:51:40 - 1.116
+++ sbin/ipfw/ipfw.814 Dec 2002 22:17:17 -
@@ -21,6 +21,9 @@
.Cm flush
.Nm
.Op Fl q
+.Cm unbreak
+.Nm
+.Op Fl q
.Brq Cm delete | zero | resetlog
.Op Cm set
.Op Ar number ...
@@ -179,6 +182,16 @@
and
.Cm resetlog
commands.
+.Pp
+When upgrading your kernel and userland you may wind up in a situation
+where
+.Nm
+is unable to add rules due to a kernel/userland mismatch. If you depend
+on NFS as your install source this can result in a no-win situation.
+You can use the
+.Cm unbreak
+command to flush and install a simple pass-through rule that will allow
+you to get your network up and running so you can resolve the problem.
.Pp
Also, each rule belongs to one of 32 different
.Em sets
Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c 26 Nov 2002 22:53:14 - 1.18
+++ sbin/ipfw/ipfw2.c 14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
}
+static void
+unbreak()
+{
+ if (!do_force !do_quiet) { /* need to ask user */
+ int c;
+
+ printf(Are you sure? [yn] );
+ fflush(stdout);
+ do {
+ c = toupper(getc(stdin));
+ while (c != '\n' getc(stdin) != '\n')
+ if (feof(stdin))
+ return; /* and do not flush */
+ } while (c != 'Y' c != 'N');
+ printf(\n);
+ if (c == 'N') /* user said no */
+ return;
+ }
+ if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0) 0)
+ err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+ if (!do_quiet)
+ printf(Flushed all rules and installed a pass-through.\n);
+}
+
static int
ipfw_main(int ac, char **av)
{
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+ else if (!strncmp(*av, unbreak, strlen(*av)))
+ unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 - 1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
#defineIP_FW_ZERO 53 /* clear single/all firewall counter(s) */
#defineIP_FW_GET 54 /* get entire firewall rule chain */
#defineIP_FW_RESETLOG 55 /* reset logging counters */
+#defineIP_FW_UNBREAK 56 /* flush and install a pass-thru rule */
#defineIP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */
#defineIP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.20
diff -u -r1.20 ip_fw2.c
--- sys/netinet/ip_fw2.c15 Dec 2002 09:44:02 - 1.20
+++ sys/netinet/ip_fw2.c15 Dec 2002 19:36:54 -
@@ -2457,7 +2457,7 @@
* Disallow modifications in really-really secure mode, but still allow
* the logging counters to be reset.
*/
- if (sopt-sopt_name == IP_FW_ADD ||
+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
@@ -2535,6 +2535,7 @@
break;
case IP_FW_FLUSH:
+
Re: ipfw userland breaks again.
: :On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon :[EMAIL PROTECTED] said: : : Now you are forcing me to go to core. It's absolutely ridiculous and : you know it. Goddamn it, next time I won't even bother posting if all : I get is this sort of crap. : :All the better, if you refuse to be civil to your fellow developers. : :-GAWollman If people are reasonable with me, I am reasonable right back. If people are unreasonable, they shouldn't expect me to be reasonable in response. It's really that simple. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 11:41:26 -0800 (PST), Matthew Dillon [EMAIL PROTECTED] said: If people are reasonable with me, I am reasonable right back. If people are unreasonable, they shouldn't expect me to be reasonable in response. It's really that simple. As a FreeBSD developer, you are expected to be civil to your fellow developers at all times, as stated in the committers' rules. If you can't manage that, please find another project. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002, Matthew Dillon wrote: Here's a new patch. But there isn't much of a point if we do not also disallow ipfw DELETE and FLUSH. And the pipe config commands as well as anything else that changes the firewall state. Firewalls are there to protect the systems behind them. I think deleting the rule that, say, prevents spoofing is as bad as adding a rule that allows everything through :-( One other avenue would be to stick a temporary check for ABI compat in installworld before overwriting ipfw. Or for the next few releases, build both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by default). You could fall back to ipfw1 if ipfw2 returns an error code in rc scripts. I'd prefer this kind of hack in the install/rc process, not in a new API. Regarding civility to developers, there are a ton of frustrating things in any project. I think civility should be the response given to both reasonable and unreasonable people. If they are unreasonable, giving a reasonable response just makes them look bad. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
What it comes down to is what developers are willing to do. My contribution is 'ipfw unbreak'. If someone else has a solution that they are willing to work on and commit in the next four weeks, then fine. But if nobody is willing to work on and commit another solution in the next four weeks then I should be able to commit my solution now, which really isn't all that bad hack or not. Any build-related solution would have to be handled by both installworld and installkernel. Consider the fact that most developers, when working on -current, install the kernel far more often then they install the world. An API check during the installkernel would work almost as well for my own purposes as 'ipfw unbreak'. It doesn't provide a failsafe but it does handle the most common installation case. Note that this solution may not be quite as simple as it appears, since -current may be built on a -stable box so compiling up an out-of-date ipfw is not entirely trivial. My current solution is on the table. I see no others on the table at the moment. -Matt :One other avenue would be to stick a temporary check for ABI compat in :installworld before overwriting ipfw. Or for the next few releases, build :both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by :default). You could fall back to ipfw1 if ipfw2 returns an error code in :rc scripts. I'd prefer this kind of hack in the install/rc process, not :in a new API. : :Regarding civility to developers, there are a ton of frustrating things in :any project. I think civility should be the response given to both :reasonable and unreasonable people. If they are unreasonable, giving a :reasonable response just makes them look bad. : :-Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: then, as usual, IPFW with the new kernel and old world fails utterly and now the fragging machine can't access the Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:
:On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
: then, as usual, IPFW with the new kernel and
: old world fails utterly and now the fragging machine can't access the
:
:Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys.
How about something like this (patch enclosed). If there are no
objections I will commit it along with a documentation update, and
maybe also add some RC code give the sysad a chance to ipfw unbreak if
ipfw otherwise fails during the boot sequence.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c 26 Nov 2002 22:53:14 - 1.18
+++ sbin/ipfw/ipfw2.c 14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
}
+static void
+unbreak()
+{
+ if (!do_force !do_quiet) { /* need to ask user */
+ int c;
+
+ printf(Are you sure? [yn] );
+ fflush(stdout);
+ do {
+ c = toupper(getc(stdin));
+ while (c != '\n' getc(stdin) != '\n')
+ if (feof(stdin))
+ return; /* and do not flush */
+ } while (c != 'Y' c != 'N');
+ printf(\n);
+ if (c == 'N') /* user said no */
+ return;
+ }
+ if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0) 0)
+ err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+ if (!do_quiet)
+ printf(Flushed all rules and installed a pass-through.\n);
+}
+
static int
ipfw_main(int ac, char **av)
{
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+ else if (!strncmp(*av, unbreak, strlen(*av)))
+ unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 - 1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
#defineIP_FW_ZERO 53 /* clear single/all firewall counter(s) */
#defineIP_FW_GET 54 /* get entire firewall rule chain */
#defineIP_FW_RESETLOG 55 /* reset logging counters */
+#defineIP_FW_UNBREAK 56 /* flush and install a pass-thru rule */
#defineIP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */
#defineIP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.19
diff -u -r1.19 ip_fw2.c
--- sys/netinet/ip_fw2.c20 Nov 2002 19:07:27 - 1.19
+++ sys/netinet/ip_fw2.c14 Dec 2002 21:41:52 -
@@ -2535,6 +2535,7 @@
break;
case IP_FW_FLUSH:
+ case IP_FW_UNBREAK:
/*
* Normally we cannot release the lock on each iteration.
* We could do it here only because we start from the head all
@@ -2551,6 +2552,22 @@
s = splimp();
free_chain(layer3_chain, 0 /* keep default rule */);
splx(s);
+
+ /*
+* If unbreaking the rulechain, which a sysad may have to do
+* if IP_FW_ADD fails due to a userland/kernelland mismatch,
+* install a pass-through rule.
+*/
+ if (sopt-sopt_name == IP_FW_UNBREAK) {
+ rule = (struct ip_fw *)rule_buf; /* XXX do a malloc */
+ bzero(rule, sizeof(*rule));
+ rule-rulenum = 2;
+ rule-cmd_len = 1;
+ rule-set = 1;
+ rule-cmd[0].len = 1;
+ rule-cmd[0].opcode = O_ACCEPT;
+ error = add_rule(layer3_chain, rule);
+ }
break;
case IP_FW_ADD:
Index: sys/netinet/raw_ip.c
===
RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.107
diff -u -r1.107 raw_ip.c
--- sys/netinet/raw_ip.c20 Nov 2002 19:00:54 - 1.107
+++ sys/netinet/raw_ip.c14 Dec 2002 21:33:58 -
@@ -399,6 +399,7 @@
Re: ipfw userland breaks again.
Matthew Dillon wrote: : :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: : then, as usual, IPFW with the new kernel and : old world fails utterly and now the fragging machine can't access the : :Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable at module load time using a kernel environment variable. Looks to me that it would do what you want. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable :at module load time using a kernel environment variable. Looks to me :that it would do what you want. : :Maxime No, this isn't what I want. I want something that can be articulated without having to reboot the whole system. The last time this happened to me, which was today, I had to reboot the system FIVE times before I got the network working again. For example, I tried rebooting into an old kernel and the fragging boot code tried to load the new kernel's ACPI module (actually it tried to load BOTH the old and new kernel's ACPI modules), and it panic'd of course. It took five attempts before I managed to get something that worked with the network up and then I had to reboot *AGAIN* to do the installworld with the new kernel. It's beginning to feel like a windows install! When you are sitting at a boot prompt and have no access to manual pages and such, and no in-boot-help that's significant enough to be worthwhile, it's no help tearing your hair out trying to remember the name of the stupid boot variable. The last thing I want is yet another undocumented or hard-to-find boot variable. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Matthew Dillon wrote: :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable :at module load time using a kernel environment variable. Looks to me :that it would do what you want. No, this isn't what I want. I want something that can be articulated without having to reboot the whole system. You don't need to reboot with this patch. As I already said it, it's a *module load time* tunable. So if you use ipfw as a module, it will do what you want. If you don't, it's of course useless. Now I would really dislike seeing your patch in the tree, since I consider it's a rather crude hack to circumvent the ABI problems of ipfw. As I've already said to luigi in private e-mail (I would be surprised if this hasn't been already discussed in the lists as well), the proper way to fix this problem is to separate the kernel and userland structures of ipfw, and add versioning to the struct. This can be done without even breaking the ABI again, since several pointers in the kernel structures are useless to userland (like the next field) and can be reused to implement structure versioning. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:Now I would really dislike seeing your patch in the tree, since I :consider it's a rather crude hack to circumvent the ABI problems of :ipfw. As I've already said to luigi in private e-mail (I would be :surprised if this hasn't been already discussed in the lists as well), :the proper way to fix this problem is to separate the kernel and :userland structures of ipfw, and add versioning to the struct. : :This can be done without even breaking the ABI again, since several :pointers in the kernel structures are useless to userland (like the next :field) and can be reused to implement structure versioning. : :Cheers, :Maxime If/when Luigi fixes the ABI problems with IPFW, we can remove this 'hack'. Until then, I do not consider the hackiness nature of the patch sufficient reason to not put it in. I've been bitten by this problem dozens of times, and wasted many hours simply because I couldn't get the damn network working, and so have others. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:Now I would really dislike seeing your patch in the tree, since I :consider it's a rather crude hack to circumvent the ABI problems of :ipfw. As I've already said to luigi in private e-mail (I would be :surprised if this hasn't been already discussed in the lists as well), :the proper way to fix this problem is to separate the kernel and :userland structures of ipfw, and add versioning to the struct. : :This can be done without even breaking the ABI again, since several :pointers in the kernel structures are useless to userland (like the next :field) and can be reused to implement structure versioning. : :Cheers, :Maxime If/when Luigi fixes the ABI problems with IPFW, we can remove this 'hack'. Until then, I do not consider the hackiness nature of the patch sufficient reason to not put it in. I've been bitten by this problem dozens of times, and wasted many hours simply because I couldn't get the damn network working, and so have others. I disagree with committing this hack; keep it as a local mod if you must. As to the problem; don't wait for Luigi to fix the ABI problems, do it yourself. Good things happen when folks are PO'd and won't settle for the status quo. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:I disagree with committing this hack; keep it as a local mod if you must. : :As to the problem; don't wait for Luigi to fix the ABI problems, do it :yourself. Good things happen when folks are PO'd and won't settle for the :status quo. : :Sam I'm sorry you disagree, but it doesn't change my position. I am not in the business of rewriting other people's APIs. If it means so much to you, YOU go and fix it. No? Then don't complain about my fix. It's no skin off your nose and it will prevent a lot of future headaches, especially if the RC system makes it nice and friendly. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
