3 ms·

Tailscaled runs as root. Is there a way to confine it, without losing functionality? As it connects many devices in my network, a vulnerability in Tailscale wi

by aborsy 3y ago

Tailscaled runs as root. Is there a way to confine it, without losing functionality? As it connects many devices in my network, a vulnerability in Tailscale will have a significant impact (they had recently a nearly 10 CVE). That’s not the case with the standard client server approach (clients can run user space Wireguard). Even though I don’t open ports with Tailscale (more precisely, I outsource them to Tailscale), I still can’t sleep well at night!

deceptive-footy 3y ago
Could be wrong here but I believe you only need to run as root once for setup. The daemon can be run as a non-root user just fine Source: that's how I run it on Arch
- ac29 3y ago
  Are you sure? I set up tailscale recently on Arch and the daemon is definitely running via a systemd system service (not a user service).
  - Bu9818 3y ago
    I don't know the case for tailscale but systemd system services can definitely be run under a specific user/group and have sandboxing applied.
  - MrDrMcCoy 3y ago
    You can easily override the service unit to confine it to an unprivileged user and then assign the net admin syscap do it can do what it needs to do.
strangecyan 3y ago
There's a userspace networking mode that pulls it out of the kernel? https://tailscale.com/kb/1112/userspace-networking/ https://tailscale.com/kb/1112/userspace-networking/
tailscaletom 3y ago
Userspace mode might be an option (runs without a TUN or doing any system network wiring, at the expense of performance): https://tailscale.com/kb/1112/userspace-networking/ https://tailscale.com/kb/1112/userspace-networking/ Running Tailscale without privileges is a challenge because tailscaled needs to be able to configure your network, and if you enable Tailscale SSH it also needs to be able to create sessions for configured users. For people who dont need SSH and accept this challenge + maintenance burden, it is possible: https://tailscale.com/kb/1279/security-node-hardening/ https://tailscale.com/kb/1279/security-node-hardening/
- aborsy 3y ago
  Thanks! I assume for DNS it also needs to modify resolv.conf as root when needed.
  - tailscaletom 3y ago
    Yepp! Strong recommend on using systemd-resolvd, we've observed the least bugs and issues there.

by aborsy 3y ago

deceptive-footy 3y ago

Could be wrong here but I believe you only need to run as root once for setup. The daemon can be run as a non-root user just fine Source: that's how I run it on Arch

ac29 3y ago
Are you sure? I set up tailscale recently on Arch and the daemon is definitely running via a systemd system service (not a user service).
- Bu9818 3y ago
  I don't know the case for tailscale but systemd system services can definitely be run under a specific user/group and have sandboxing applied.
- MrDrMcCoy 3y ago
  You can easily override the service unit to confine it to an unprivileged user and then assign the net admin syscap do it can do what it needs to do.

strangecyan 3y ago

There's a userspace networking mode that pulls it out of the kernel? https://tailscale.com/kb/1112/userspace-networking/ https://tailscale.com/kb/1112/userspace-networking/

tailscaletom 3y ago

Userspace mode might be an option (runs without a TUN or doing any system network wiring, at the expense of performance): https://tailscale.com/kb/1112/userspace-networking/ https://tailscale.com/kb/1112/userspace-networking/ Running Tailscale without privileges is a challenge because tailscaled needs to be able to configure your network, and if you enable Tailscale SSH it also needs to be able to create sessions for configured users. For people who dont need SSH and accept this challenge + maintenance burden, it is possible: https://tailscale.com/kb/1279/security-node-hardening/ https://tailscale.com/kb/1279/security-node-hardening/

aborsy 3y ago
Thanks! I assume for DNS it also needs to modify resolv.conf as root when needed.
- tailscaletom 3y ago
  Yepp! Strong recommend on using systemd-resolvd, we've observed the least bugs and issues there.