From owner-freebsd-security Thu Jul 30 01:01:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25505 for freebsd-security-outgoing; Thu, 30 Jul 1998 01:01:46 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25498 for ; Thu, 30 Jul 1998 01:01:44 -0700 (PDT) (envelope-from bs@devnull.ruhr.de) Received: (from admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id JAA00731; Thu, 30 Jul 1998 09:34:52 +0200 (MET DST) Received: from [192.168.22.75] (helo=rm.devnull.ruhr.de) by devnull.ruhr.de with esmtp (Exim 1.92 #1) id 0z1d6f-00013b-00; Wed, 29 Jul 1998 22:45:53 +0200 Received: from bs by rm.devnull.ruhr.de with local (Exim 1.92 #1) id 0z1d6d-0000lG-00; Wed, 29 Jul 1998 22:45:51 +0200 To: sthaug@nethelp.no Cc: benedikt@devnull.ruhr.de, marcs@znep.com, ben@rosengart.com, security@FreeBSD.ORG Subject: Re: inetd enhancements (fwd) References: <87af5um74j.fsf@devnull.ruhr.de> <2983.901735734@verdi.nethelp.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Benedikt Stockebrand Date: 29 Jul 1998 22:45:50 +0200 In-Reply-To: sthaug@nethelp.no's message of "Wed, 29 Jul 1998 20:08:54 +0200" Message-ID: <87d8aos7wh.fsf@devnull.ruhr.de> Lines: 56 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no writes: [Re: Filtering packets coming in through the "wrong" interface] > > I'd use a packet filter for that, something like > > Certainly you can do that - but it seems like a rather heavyweight > method of solving this particular problem. I'd like to have something > that could be twiddled with sysctl myself. Point taken. But let me play the advocatus diaboli for a moment: - If we put everything that may be reasonable for some people and/or situations into the kernel we risk to end up with a system that's as sluggish as Solaris (not to mention something like NT). - As long as we're dealing with security, a smaller system is inherently less insecure because it'll contain less bugs. The filter you propose doesn't provide additional functionality that can't be done through the packet filter mechanism. To achieve maximum "orthogonality" it should be left out. - If your system lives on a network with potentially malicious packets coming in, you better use a proper packet filter anyway as part of securing that machine properly. If you don't have to worry about possible attacks (because you've got a firewall in place and trust the local machines) you don't really need for such a filter. As a consequence there shouldn't be the widespread use for this feature to justify it being put into the kernel. Of course I'm somewhat biased because I think that the only way to build a reasonably secure system is to stick with those abstract rules of thumb like "maximizing orthogonality" and "minimizing total system size" and such. And since I feel reasonably comfortable setting up a packet filter I don't feel as much of a pressing need for this feature as someone who's only started trying to figure out what a packet filter is. Anyway, your proposal isn't something I'd feel like getting religious about. If someone provides the code and someone with commit privilege is willing to integrate it into the source tree I'd just go on with life as before :-) So long, Ben -- Ben(edikt)? Stockebrand Un*x SA My name and email address are not to be added to any list used for advertising purposes. Any sender of unsolicited advertisement e-mail to this address im- plicitly agrees to pay a DM 500 fee to the recipient for proofreading services. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message