On Sun, 18 Oct 2015 19:20:47 +0200 Rob van der Hoeven robvanderhoeven@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,