From owner-freebsd-security Thu Feb 4 11:55:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11370 for freebsd-security-outgoing; Thu, 4 Feb 1999 11:55:58 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11362 for ; Thu, 4 Feb 1999 11:55:55 -0800 (PST) (envelope-from mike@seidata.com) From: mike@seidata.com Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id OAA27662; Thu, 4 Feb 1999 14:55:25 -0500 (EST) Date: Thu, 4 Feb 1999 14:55:25 -0500 (EST) To: James Wyatt cc: Sheldon Hearn , Chris Larsen , security@FreeBSD.ORG Subject: Re: Enabling bpf device in kernel (was: Re: tcpdump) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Feb 1999, James Wyatt wrote: > While I understand your point, it smacks of elitism. Many of the admins > clue-level started at the lame-level hacking on their own machine. Some No, it doesn't 'smack[..] of elitism', it makes a very good point: many of the users of FreeBSD (or any OS) will have to clue what bpf is - or how to disable it if they do not want it running. It is not wise to put tools in the hands or people without their knowing what those tools are or how to use them - especially something with bpf's implications. As it is now, one must research bpf and LEARN something before mindlessly enabling it... the approach you suggest removes all effort from the process. As for a GENERIC kernel that has numerous non-needed options enabled and is overly-bloated, might I suggest http://www.microsoft.com. The main argument I have heard for including bpf is, 'it will reduce kernel compile time'. Bologna. I don't want bpf running on my production Internet machines, so I will be compiling far more just to remove the bpf support. The reduced or increased kernel compile time is not the issue, anyway... since anyone who has used FreeBSD (or any Unix) for long at all will be re-compiling their kernel. It is no harder to add 'pseudo-device bpf 2' than it is to remove 'pseudo-device bpf 2'. The issue is remembering what GENERIC is for. It's not meant to hold every possible kernel option under then sun... Heck, why not just mv LINT GENERIC? > us - especially if they read the lists and a doc or two. Adding BPF isn't > like putting the RedHat CD on my Multia and seeing it install NFS and Actually, it's heading down the same slippery slope... enable as much by default as possible so the unknowing user can utilize as many utilities as possible... Down side? Loss of efficiency and lack of security. -- Mike Hoskins System/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message