From owner-freebsd-security Thu Sep 16 12:10:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 795B214ECF for ; Thu, 16 Sep 1999 12:10:32 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id PAA20829; Thu, 16 Sep 1999 15:06:53 -0400 (EDT) Date: Thu, 16 Sep 1999 15:06:53 -0400 (EDT) From: Kenny Drobnack To: Brett Glass Cc: "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915170025.048d0b00@localhost> 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 How about this idea: from what I've seen and heard, the only things that depend on BPF are tcpdump and dhcp. The average user does not need tcpdump. So, if a user enables dhcp, BPF gets turned on, otherwise, it will stay off. Of course, the only way I could think of to do this would be to make BPF a loadable module. The problem with that is, someone running as root could just load up the module anyway... > Maybe it's a religious issue, or maybe some utility depends on it. > But it might not be a good idea to let it be on from the get-go. > If the machine is rooted, you've got an instant packet sniffer. > I plan to turn it off on EVERY install, and I sure wish it > were that way to start. ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" -the Knights who formerly said "ni" "Monty Python and the Holy Grail" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message