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

[Yawning Angel]

On Sun, 18 Oct 2015 19:20:47 +0200
Rob van der Hoeven <robvanderhoeven at ziggo.nl> wrote:

> 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.

Yeah.  Since your receive window isn't ever sizable, and the interface
is rather reliable, this behavior is probably the simplest.

[snip]
> >  * 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.

Arch.  It's a rolling release system, and it's up to date-ish.  It's
not a big deal at the moment...

> >  * 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.

Oh, well.  Using setcap and granting the relevant capabilities also
works, though dropping the capabilities requires a bit more work.  The
elevated capabilities aren't persisted across exec() at least so the
child side handling is easy.
 
> 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

Well. Debian requires enabling it by writing to proc (they have a patch
for this).  Arch flat out doesn't include support for that in the
vanilla kernel (https://bugs.archlinux.org/task/36969?project=1), ditto
anyone using grsec.

It's probably not that much code to support user namespaces, running
with just the required capabilities, and running as suid root in the
same code base.

> >  * 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.

Ah I see (I assume/hope you'll fix this anyway).

(Will there also ever be an option for configuring a different tun
address?)

Neat project.  I'll be looking forward to subsequent releases, since
this is slick, and I think a better approach than torsocks once it
matures a bit.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151018/943c7c97/attachment.sig>