On Sun, 18 Oct 2015 19:20:47 +0200 Rob van der Hoeven <robvanderhoeven@xxxxxxxx> 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
Attachment:
pgpK9NjXLi6Gf.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev