From owner-freebsd-security Fri Sep 17 12:41:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9628114F6E for ; Fri, 17 Sep 1999 12:41:01 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA82654; Fri, 17 Sep 1999 13:41:00 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA04615; Fri, 17 Sep 1999 13:39:58 -0600 (MDT) Message-Id: <199909171939.NAA04615@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Cy Schubert - ITSD Open Systems Group , Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 10:15:02 MDT." <4.2.0.58.19990916100439.048ebd70@localhost> References: <4.2.0.58.19990916100439.048ebd70@localhost> Date: Fri, 17 Sep 1999 13:39:58 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990916100439.048ebd70@localhost> Brett Glass writes: : 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? BPF isn't architected to allow this, so doing it effectively would be non-trivial. Also, if I can run any kernel code at all as an intruder, I can reset this simple flag and you'd never know about it. Single flags in the kernel can easily be abused if your system isn't completely and totally locked down. I don't want to encourage people to create a switch that is as easy to turn on as it is to turn off. My main objection to this is that you are looking at the wrong problem here. If I have rooted your system, I can generally cause arbitrary code to run at boot time before the secure level is changed because I've yet to see a system that is secured well enough to prevent it. The level of effort required to close all these wholes is about an order of magnitude larger than rebuilding he kernel with the bpf code removed. The best solution would be to have the IP stack that could deal with the needs of dhcp. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message