Date: Thu, 16 Sep 1999 10:15:02 -0600 From: Brett Glass <brett@lariat.org> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <4.2.0.58.19990916100439.048ebd70@localhost> In-Reply-To: <199909161409.HAA06535@cwsys.cwsent.com> References: <Your message of "Wed, 15 Sep 1999 20:12:54 MDT." <4.2.0.58.19990915200910.048dba50@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Bob Vaughan has sent me e-mail stating that he doesn't want this discussion to erupt into the tug of war it did last time, and wanted to kill it. After looking over the archives, I can see why! However, there are several useful and productive ideas in Cy's message that are definitely NOT flamage, so I'd like to send a short message in support of them. At 07:09 AM 9/16/99 -0700, Cy Schubert - ITSD Open Systems Group wrote: >How about a compromise? Leave BPF in the generic kernel but add a boot >option to disable it, then a site can create a loader.conf to to >disable it. To enable it an intruder would have to modify loader.conf >and reboot. This would surely be noticed -- noticed as much as an >intruder building a new kernel with BPF and rebooting. This approach >will have the advantage of leaving BPF disabled even after an upgrade. Yep, and if someone tries to turn it on, Tripwire will catch them. To do this, the BPF driver needs to have a visible switch you can hit to disable it, as do other drivers. I forget the exact data structures involved, but I know it's not hard. Anyone have this information on the top of his/her head? >To satisfy any new install requirements, create a sysinstall option or >question to disable it during install. We could even create a >make.conf option to add this option to loader.conf during make >installworld. I like this idea too. >Personally, I don't see why people are so impassioned about this. I >and my team build a custom kernels for each FreeBSD, Tru64 UNIX, and >Linux system we maintain and usually maintain custom /etc/system files >for our Solaris boxes. We put in the kernel only what the kernel will >use on a system, making the kernel as small as possible. Normally we >disable BPF, however in cases where customers (usually developers) have >many complaints about inaccessibility of a host or service, we turn on >BPF, as it helps diagnose problems much more quickly. > >If you build custom kernels, as I think one should, this whole issue is >irrelevant. I build custom kernels a LOT. But some of my clients go out and buy a FreeBSD disk (on my advice) and put up new machines without knowing the first thing about compiling a kernel. They then have a potential sniffer on their network, and adding Tripwire won't help unearth abuses. Since this is probably an easy PR, let's at least submit it. Again, can anyone here coach or remind me about that data structure? --Brett 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?4.2.0.58.19990916100439.048ebd70>