On Mon, Jan 30, 2012 at 8:23 AM, Mike Perry mikeperry@torproject.org wrote:
Thus spake K. Macy (kmacy@freebsd.org):
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.
- 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