From owner-freebsd-security Thu Feb 4 02:35:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA21862 for freebsd-security-outgoing; Thu, 4 Feb 1999 02:35:41 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA21855 for ; Thu, 4 Feb 1999 02:35:34 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.11 #1) id 108M6T-000EIx-00; Thu, 4 Feb 1999 12:33:45 +0200 From: Sheldon Hearn To: Chris Larsen cc: security@FreeBSD.ORG Subject: Re: Enabling bpf device in kernel (was: Re: tcpdump) In-reply-to: Your message of "Thu, 04 Feb 1999 10:07:34 +0100." Date: Thu, 04 Feb 1999 12:33:45 +0200 Message-ID: <54990.918124425@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 04 Feb 1999 10:07:34 +0100, Chris Larsen wrote: > As for security.=20 > Yes its bad that bpf is enabled on a vanilla install, not > all *bsd users are ethical about their use of promiscious mode NIC. Sorry, I _still_ don't think I understand why bpf is "bad for security". The only thing I can think of is that "bpf is bad for security when root is hacked on the box". I'm wrong if promiscuous mode is available to non-root users. Looking at the arguments put forward on this issue so far, I'd suggest that the following is reasonable: 1) It's unlikely that root on a brand new box is going to be cracked into within the first few minutes of its life. If it is, you have a very unpleasant "leak" in your admin team. 2) Even if the box is _not_ bpf-enabled, a root break-in will change all that with a single reboot. It's easy to guess a time at which such a reboot is likely to go unnoticed for a while. If you're happy with that, then this whole issue becomes really simple. It all boils down to a choice: 1) Do we try to protect lame admins from horrible things that may happen later on if root is hacked on the box by taking bpf out of the GENERIC kernel? 2) Do we accept that the kind of lame admin who doesn't understand the risks involved in using a bpf-enabled kernel is unlikely to notice the reboot that enables bpf after some unfortunate sniffing, and therefore the damage we wanted to protect him from in the first place, has been done? I think that we'll find this issue easy to resolve by focusing on those two questions. Specifically, I think the focus should be on _who_ we are trying to serve best, the cluefull or the lame. It's my opinion that what we gain by shipping a bpf-less kernel does not measure up to the loss of functionality imposed. Remember, we only gain for lame admins. I hope I've made a useful contribution to this thread, since I'd really like for a final decision to come out of it, one way or another. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message