Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Sep 1999 13:39:58 -0600
From:      Warner Losh <imp@village.org>
To:        Brett Glass <brett@lariat.org>
Cc:        Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, 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:  <199909171939.NAA04615@harmony.village.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>  <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
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909171939.NAA04615>