[tor-dev] Another Virtual Network Environment needs your I/O
yawning at schwanenlied.me
Sun Oct 18 18:31:12 UTC 2015
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
Yeah. Since your receive window isn't ever sizable, and the interface
is rather reliable, this behavior is probably the simplest.
> > * 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the tor-dev