4 ms·

I tried to use similar LD_PRELOAD solutions but I always ended up finding some programs that don't go through libc, so they bypassed the VPN. badvpn-tun2socks

I tried to use similar LD_PRELOAD solutions but I always ended up finding some programs that don't go through libc, so they bypassed the VPN. badvpn-tun2socks works with everything I wanted, but it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up.

a-dub 6y ago
i'm curious which programs bypass libc for socket stuff. making direct syscalls is exceedingly rare in my experience.
- sigotirandolas 6y ago
  I don't remember exactly, but I believe I was related to Java, probably trying to debug some Java app with IntelliJ. I'm not 100% sure if the problem was due to some intrinsic LD_PRELOAD/libc limitation or something related to the tools I tried, but trying to find what the problem was with something so gigantic seemed impossible so I went the tun2socks way which is more transparent for applications. (Also Go programs are famous for bypassing libc.)
  - a-dub 6y ago
    hmm. that's super weird. at the very least i would expect them to use the low level syscall wrappers in the libc. unless they're avoiding linking libc at all, it seems super weird to be making syscalls directly from application code. i mean, what are they doing? implementing the syscall gate by hand. why would anybody do that?
  - a-dub 6y ago
    anyway the reason i bring it up is that i've been toying with the idea of lightweight ld_preload "containers" which patch the relevant syscalls to mount additional filesystem and network resources in a safe and extremely high performance manner by bypassing the kernel completely.
  - a-dub 6y ago
    ahh. i see now.. portability... i bet it would be possible to bypass/patch sysenter to achieve the same aim even if they're implementing their own syscall gates.
  - natmaka 6y ago
    Maybe because the binary was statically linked. Go binaries are.
sedachv 6y ago
> it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up. OpenBSD routing domains make this really easy.

a-dub 6y ago

i'm curious which programs bypass libc for socket stuff. making direct syscalls is exceedingly rare in my experience.

sigotirandolas 6y ago
I don't remember exactly, but I believe I was related to Java, probably trying to debug some Java app with IntelliJ. I'm not 100% sure if the problem was due to some intrinsic LD_PRELOAD/libc limitation or something related to the tools I tried, but trying to find what the problem was with something so gigantic seemed impossible so I went the tun2socks way which is more transparent for applications. (Also Go programs are famous for bypassing libc.)
- a-dub 6y ago
  hmm. that's super weird. at the very least i would expect them to use the low level syscall wrappers in the libc. unless they're avoiding linking libc at all, it seems super weird to be making syscalls directly from application code. i mean, what are they doing? implementing the syscall gate by hand. why would anybody do that?
- a-dub 6y ago
  anyway the reason i bring it up is that i've been toying with the idea of lightweight ld_preload "containers" which patch the relevant syscalls to mount additional filesystem and network resources in a safe and extremely high performance manner by bypassing the kernel completely.
- a-dub 6y ago
  ahh. i see now.. portability... i bet it would be possible to bypass/patch sysenter to achieve the same aim even if they're implementing their own syscall gates.
- natmaka 6y ago
  Maybe because the binary was statically linked. Go binaries are.

sedachv 6y ago

> it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up. OpenBSD routing domains make this really easy.