[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: blocking DHCP requests



On Sunday 03 October 2004 01:10, Camiel Dobbelaar wrote:
> dhcpd (like tcpdump) uses bpf/libpcap, which gets a copy of the network
> data before pf does.  This means you cannot use pf to filter what gets to
> dhcpd.
Quoting from here: http://www.onlamp.com/lpt/a/4839
Federico: If I'm not wrong, tools that use raw access to network data bypass 
PF because the filtering happens after. How can this be solved? Is this a 
behavior you want to change?
HB: This is not true.
It is true that bpf is outside pf. This is actually very good for debugging.
We might add a possibility for bpf-based tools to request to be hooked in 
before pf. It might be useful for the dhcp programs. But then, that is not a 
real-world problem â I have privilege revoked dhcpd and dhcrelay so that they 
don't run as root anymore, and [email protected] helped out with bpf write filters (we 
have read filters already) and lock the bpf device so that no changes in 
those filters are possible anymore. Especially for dhcpd that means that one 
very worrysome piece of code is now locked away that nicely that you don't 
have to worry much anymore. And of course besides the privdrop and bpf 
security work, we cleaned that mess up big time...
The most worrysome of those programs is now dhclient which is scary, huge and 
still runs as root â even given we cut about half of its code out already. I 
have it running privilege separated on my machine already...
RM: I don't see this as a problem, and don't think that this will be changed.
CEA: This is by design, and I do not want/see this behavior changing. We have 
introduced bpf security extensions to solve this problem on a case-by-case 
basis. We are going through every program in the tree and modify them to use 
the security extensions and drop/separate privileges. At some point we may 
also start looking at critical applications in the ports tree. 
Who's right ?
	Ed