From owner-freebsd-current Thu Jun 13 12:42:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13926 for current-outgoing; Thu, 13 Jun 1996 12:42:34 -0700 (PDT) Received: from critter.tfs.com (critter.cdrom.com [204.216.27.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA13920 for ; Thu, 13 Jun 1996 12:42:28 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id MAA03323 for ; Thu, 13 Jun 1996 12:42:16 -0700 (PDT) To: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Subject: Re: #include opt_ipfw.h problem for lkm In-reply-to: Your message of "Thu, 13 Jun 1996 13:26:13 EDT." <9606131726.AA09438@halloran-eldar.lcs.mit.edu> Date: Thu, 13 Jun 1996 12:42:15 -0700 Message-ID: <3321.834694935@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I object STRONGLY to removing the ipfw LKM. What would we gain ? -- nothing. What would we loose ? -- a feature. You argument that an intruder just has to unload the lkm is bogus. If you used ipfw for sercurity purposes, you would NOT use the LKM in the first place. Second, if you did, you would surely be running with a secure-level that prevented the unloading of the lkm. "Doctor! doctor! It hurts when I do this!" -- "Don't do that then!" The point of having it as an LKM, is that you can use it to remove traffic that you don't want, ie. use it as a network tool not a security device as such. I have used it to do things like filter out RIP from a bogus router or merely logging of traffic from a particular host. Neither of these uses warranted a hyper-secure setup, and being able to load ipfw was just the thing to do the job. Why would we kill a feature like that ? I will conceede to Garretts argument of speed, and you can add: #ifdef INET_REALLY_FAST around the two function calls as long as you don't put it in GENERIC. According to your logic I expect you to advocate the removal of ufs-async, ext2fs, msdosfs not to mention rm features because they are dangerous if used wrong. :-) Remember that FreeBSD is not in the business of enforcing any policy but provide the tools for others to enforce their own chosen policies... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.