Thus spake K. Macy (kmacy@xxxxxxxxxxx): > 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? 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?
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev