[tor-dev] Fwd: Tor Transports

[K. Macy]

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