From owner-freebsd-security Thu Feb 4 13:45:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25562 for freebsd-security-outgoing; Thu, 4 Feb 1999 13:45:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA25550 for ; Thu, 4 Feb 1999 13:45:05 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (5429 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 4 Feb 1999 15:19:57 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Thu, 4 Feb 1999 15:19:56 -0600 (CST) From: James Wyatt To: mike@seidata.com 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 mike@seidata.com wrote: > 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. Please quote the original material when refuting, especially if you didn't write it, know what the author had in his mind, and how the reader took it. The choice of words just struck me wrong, that's all. 8{( If it is so easy to add (just another few lines in the hack script), we aren't making it much safer leaving it out. DHCP is rapidly appearing everywhere and our stack can't handle it w/o BPF until it is reworked or repaired. Lots of folks are using FreeBSD as a client and the server folks often have to rebuild their kernels anyway. My main concernis ae fitting on one floppy and works-everywhere. I'm happy with generic, but would like more. > As for a GENERIC kernel that has numerous non-needed options enabled > and is overly-bloated, might I suggest http://www.microsoft.com. I wasn't aware they had a GENERIC BSD kernel available, could run on my hardware and customer mix, or shipped anything I could trust naked on The Net. I wasn't aware that any 'if you don't like it go to The Devil in Redmond' comments were apropo around here. ('You can go to Linux' is just as bad.) I run numerous OSs around here, but most are behind a FreeBSD firewall. Besides, XBoing doesn't run on Win32. 8{) > 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. Since you hint you can run all your servers w/GENERIC if bpf is not in it, why not build a standard kernel and install it after you load FreeBSD? It's what I have gone to here to get divert-sockets for natd clients. What I am concerned about is the boot floppy and base install. Can I put a floppy in the system hooked to DHCP-administrated interface (CableMode, office LAN, etc...), and FTP/CDROM load FreeBSD and be up-on-the-air? btw: When I help friends get a 486 FreeBSD online, a precompiled kernel saves about 40/50 min each! It is about 3.5 on a K6/II. I usually convert the old machine they had before Win32 and use Pentium/K6/etc for uSoft client machine since it sucks so much CPU/RAM. > 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... Remember LKMs? We are working on getting away from rebuilding kernels where we can. It is one more thing in a machine-restore and something else folks learning Unix can misconfigure. VeryFAQs sometimes point to things that should change. > Heck, why not just mv LINT GENERIC? Because the comments on lines 7 to 9 suggest against it. Because it won't fit on the boot floppy. Because it won't load on 16MB RAM with reasonable swap. Because it will enable conflicting drivers. Because it enables the wrong CPUs. Because USER_LDT is not a good default. Because extra debug and profile code will *really* slow things down *always*. Because NFS in installed. Because quotas are enabled. Because snp means the console can be snooped. Because the world would rotate in reverse. Because my cat would explode. Oh, this was another GENERIC statement... > > 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. That *is* worth worrying about and why I'm still listening closely to what others on this list, incuding yourself, have to say. Thanks! - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message