[tor-dev] Another Virtual Network Environment needs your I/O

[Rob van der Hoeven]

On Sun, 2015-10-18 at 14:43 +0000, Yawning Angel wrote:
> > Congestion control is used to prevent dropped segments. This can not
> > happen on the User Space <-> kernel connection of a tun interface. The
> > TCP-window flow control prevents this. 
> 
> Hm.  Your code never shrinks the advertised window, and ACKs once when
> data has been added to the receive buffer.  As a perfectionist for such
> things, this makes me really sad, but since it the stack never sees the
> light of day outside a TUN interface, the behavior is probably ok.

I never adjust the size of the TCP window, that's correct. The code only
sends an ACK for data that is *removed* from the buffer. If data is
added to the buffer, the amount of data the TCP-client is allowed to
send decreases. Eventually becoming zero if no data is removed at all.

> > "Want to" implies that the user is aware of the danger. Most users
> > have no idea about the dangers of using a particular protocol over
> > Tor. I want to protect these users.
> 
> Fair enough.  I'd suggest this be configurable behavior.  See
> `WarnPlaintextPorts` in the tor manpage for what should be a sensible
> list.

Good idea.

> > > Should be easily portable to the U*IXes, Windows will give you pain,
> > > but I'm not sure you care.  
> > 
> > I care, and I think it can be ported to Windows. Since there are no
> > kernel namespaces, another way to force all traffic through the tun
> > interface must be found. It can be done by using the Windows firewall
> > like this:
> > 
> > https://community.hide.me/tutorials/bind-your-connection-to-vpn-with-windows-firewall.49/
> 
> Guess you'll use the OpenVPN TUN/TAP driver?

Yep.

One thing: At the moment I do not have the resources to work on a
Windows version of the program. Creating a consumer-grade Linux version
is my current goal. 

> 
> Some more random things:
>  * PSH is set incorrectly.  You set PSH when you're ACKing received
>    data (without piggybacked payload).  You're supposed to PSH as part
>    of sending data to the peer (See RFC 1112 4.2.2.2).

Ok.

>  * DNS resolution does not work if /etc/resolv.conf points at 127.0.0.1.
>    This probably is a documentation thing rather than a code thing.

Maybe, I will look into this.

>  * I couldn't figure out how to get X apps to work at all.
>    (Eg: chromium fails with "Gtk: cannot open display: :0")

Ah, your system probably uses an Abstract Unix Socket for communication
with the X server. Abstract Unix Sockets are created inside a network
namespace, and your X server socket lives inside the global network
namespace. To solve this I have to write proxy code to create an X
server socket inside the network namespace of the TCP client. Maybe you
can temporarily solve the problem by binding your X server socket to a
normal Unix socket? (filesystem Unix Sockets are not network namespace
aware).

What OS (name+version) are you using? I'm using Debian Wheezy which does
not have this problem.

>  * There should be documentation that this requires a minimum of
>    CAP_SYS_ADMIN (for the various unshare() calls) and CAP_NET_ADMIN (to
>    bring the tun interface up).

AVNE is a suid program at the moment. To do the privileged calls the
program runs (for a while) with root privileges.

I'm going to move to Debian Jessie. This version has a newer kernel that
supports user namespaces. As I understand it (have not played with user
namespaces), these can be used to create programs that can have full
privileges inside the user namespace without having full privileges
themselves. No more suid needed. The downside is that user namespaces
are only available for kernels with versions >= 3.8

>  * The config file load/parse routine has a trivially exploitable
>    buffer overflow.

The final config file will be owned by root and stored in /etc.

Good input Yawning!

Rob.
https://hoevenstein.nl