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? What handles ultimately wrapping up packets for your virtual interfaces on the other side of the BPF API? 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 .. ?
Also, how portable is the code that provides this virtual interface support?