Date: Thu, 4 Feb 1999 15:19:56 -0600 (CST) From: James Wyatt <jwyatt@RWSystems.net> To: mike@seidata.com Cc: Sheldon Hearn <axl@iafrica.com>, Chris Larsen <vader@vader.dk>, security@FreeBSD.ORG Subject: Re: Enabling bpf device in kernel (was: Re: tcpdump) Message-ID: <Pine.BSF.4.05.9902041428120.15871-100000@kasie.rwsystems.net> In-Reply-To: <Pine.BSF.4.05.9902041446380.15864-100000@ns1.seidata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902041428120.15871-100000>