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 canacar@ 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
