Security

What lnk vpn exit <machine> home exposes, and what it doesn't. How an agent's traffic reaches the exit, through Link's filtering proxy, is in the sandbox's security.

What's reachable

  • The exit is an ssh -R from here to the machine, over Link's SSH to a box (lnk box forward) or your own SSH setup for any other host, to a SOCKS5 server on this computer's loopback, at a free port, while the exit is up (lnk sandbox socks, so the sandbox plugin is needed).

  • That server reaches only the internet: never this computer's own addresses or loopback, its LAN, link-local or shared (CGNAT) ranges, a cloud's metadata service, the IPv6 /48 around this computer's own address, where the other devices of its network are, or its network's public IPv4 address, where some routers answer their admin page from inside. It takes addresses only and never resolves a name, so a name can't point it home. A program on the machine gets your home address, not your home.

  • On the machine, the SOCKS5 proxy is a Unix socket in your home folder, ~/.config/lnk/vpn/exit.sock, which sshd makes readable and writable by your user only (StreamLocalBindMask, 0177 by default), in a folder only yours (700). Your programs on that machine can use it; other users there and nothing on its network can. The proxy takes no password, so this is what keeps others out. No sshd setting opens a socket to the network, as GatewayPorts does a port.

  • Before each connection, the exit removes a socket a connection before left there (sshd leaves it, and binds over none), over an SSH connection of its own. So of two computers making one machine their exit, the one that connected last has the socket.

  • With --port, or for an agent on a box whose lnk is from before the socket, the proxy listens on the machine's loopback instead, 127.0.0.1:40780, while anyone holds it there. Programs of every user there can use it; nothing on its network can. An exit held from before the socket stays on the port until those holding it there give it back. An sshd with GatewayPorts yes ignores the 127.0.0.1 asked for and opens the port on every address. So on a host that isn't a box, on the port:

    • Before an exit starts, lnk vpn exit <host> home makes the same forward once, to a port here where nothing listens, and checks it. On such a host it refuses to start the exit. A host it can't reach then is left to the exit, which keeps trying.
    • The exit's SSH connection runs the check there too, through your login shell: it reads the host's listening ports (/proc/net/tcp, or netstat -an off Linux) and, when 40780 listens anywhere but loopback, or can't be seen on loopback within 5 seconds, ends the connection by ending its sshd, about a second after it prints why. That ends every connection made through the port too, so holding one doesn't keep the port open. It checks again every 10 seconds, and ends itself when the connection does.
    • Such a port is open for the moment between sshd opening it and the check ending it, one to two seconds. That happens only when a host turns GatewayPorts on after its exit started: then again each time the exit reconnects, every 10 seconds, until you fix sshd or run lnk vpn exit <host> off.

    Boxes keep sshd's default, no, and run no check.

  • An exit started by an lnk from before this proxy used ssh's own SOCKS, which reaches this computer and its LAN. The next lnk vpn exit <machine> home restarts any exit whose service differs from what this lnk would start; lnk agent move and lnk agent exit home run it. Until then, such an exit to a box is down, since lnk box forward refuses to run without a proxy to forward to. One to any other host stays as it was: run lnk vpn exit <host> home.

  • An agent's proxy on a box reaches the socket by its path; the agent itself can't: every sandbox hides the socket's folder, ~/.config/lnk/vpn, as it hides Link's settings, and when XDG_CONFIG_HOME puts the settings elsewhere it still hides that folder (making it when it's missing, so a socket put there later never shows in a running sandbox).

  • It needs no administrator rights here or on the machine.

How it learns your public address

When the exit starts, and every 5 minutes, it asks your router with NAT-PMP, and Cloudflare's STUN server (stun.cloudflare.com) which address your connections are seen from. Cloudflare sees a request from your address and nothing else. It refuses both, and keeps the last ones learned when neither answers.

Who can use your address

Any program of your user on that machine can use your home address while the exit is up, not only your agent; on the port, any program of any user there. Make a machine your exit only if what runs there is yours.

When this computer is off

With this computer off or offline, or the SSH connection down, nothing answers on the socket, or the port, and nothing gets home. An agent routed through the exit then has no internet at all: it fails closed and never falls back to the machine's own network.

Limits

  • Your network's public IPv4 address is refused only once learned: with no NAT-PMP on your router and no UDP out to STUN, it isn't. IPv6 devices of your network outside the /48 around this computer's address aren't known to it.
  • TCP only, through a SOCKS5 proxy: a program has to use it.
  • For a host that isn't a box, SSH runs with BatchMode=yes, so it must work without typing anything, and the host needs /bin/sh, and on the port either /proc/net/tcp or netstat for the check above; without them the exit stops.
  • The socket's path, home folder included, must fit a Unix socket's (about 100 characters), and the home folder's path is letters, digits and /._-+@ only; otherwise the exit can't start on the socket: use --port.
  • A machine's name is letters, digits and @._:- only, and never starts with -, so it can't be read as an SSH option.