On Mon, Jan 30, 2012 at 8:23 AM, Mike Perry <[email protected]> wrote: > Thus spake K. Macy ([email protected]): > >> On Fri, Jan 20, 2012 at 11:35 PM, Steven Murdoch wrote: >> > >> > One hop-by-hop transport protocol we will likely be considering for an >> > alternative Tor transport is TCP, and Kip Macy (a FreeBSD developer, Cc'd) >> > has been working on porting the FreeBSD network stack to userspace, with >> > the Tor use-case in mind. Unlike many other attempts though, >> > maintainability has been a primary concern, so we should be able to keep >> > in sync with the FreeBSD stack with manageable effort. > >> I have a few additional comments to add to set expectations appropriately. >> >> 1) I have a prototype "safe" BPF API whereby an unprivileged >> application can only receive and send packets on a single or >> pre-specified set of IP addresses and only advertise its private >> stack's MAC address. Without this functionality one needs to either >> layer the stack on top of kernel UDP (perfectly reasonable approach, >> just requires writing another simple virtual NIC driver) or running as >> root, whereby plebeian networking becomes a misnomer - a patrician >> poseur as it were. Having even such a simple kernel module goes >> against the grain of Tor conventions of not doing anything as root >> (although configuring things like transparent proxying require a >> certain amount of futzing as root). > > Can you explain the privilege separation of the safe BPF api?
The filter creation / installation is not handled by the unprivileged process. The most sophisticated possibility is my recollection of Robert Watson's suggestion: A dedicated privileged daemon accepts requests for an IP & mac address and returns a descriptor that is a bpf handle with the corresponding filter installed. Thus libplebnet would send a message to the daemon saying "my MAC is 80:ee:73:00:ba:be and my desired IP is 192.168.0.42", the daemon would fill out a filter template with those values, install it and then hand pass the descriptor to libplebnet. > What > handles ultimately wrapping up packets for your virtual interfaces on > the other side of the BPF API? The libplebnet process creates the packets, but if attempts to advertise a MAC other than its own or spoof source addresses the packets will be dropped by the egress filter. > Does it run as root as a daemon to manage > your virtual interface, providing the BPF API to unprivileged apps > through the LD_PRELOAD wrappers, or .. ? The daemon installing filters would run as root. The actual filtering happens in BPF at L2, see the original McCanne/Van Jacobson paper if that part is unclear. > Also, how portable is the code that provides this virtual interface > support? I think the biggest portability question is BPF itself, which I have not looked in to. My virtual ethernet driver is very simple, and my "safe BPF" extension is a handful of extra checks in BPF. Thanks, Kip _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
