5 ms·

These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here. A user-configured VPN should not run as roo

These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here. A user-configured VPN should not run as root and affect networking for the entire system; the whole VPN process should run in its own network namespace with no more privileges beyond those of the user activating it. Processes that need to use the VPN (rather than clearnet) should be attached to that same network namespace. If necessary, you can even avoid attaching a NAT (e.g.: slirp4netns) to the namespace so that if the VPN dies there is no data leakage. I get that running things as root has a bit more performance, but compromising on security for the sake of performance doesn't sound like the right approach for this kind of software.

Joker_vD 3y ago
Yeah, for some reason almost all user-specific customization of network-connectivity (VPN, DNS, etc) requires root privileges.
- Vogtinator 3y ago
  Yeah, because it affects networking in the entire system. If some pam session module were to set up its own network namespace that is shared by all user processes after login, this could be (mostly) solved. The result would be some surprising behaviour though, as processes outside have a possibly vastly different view of the network.
  - Joker_vD 3y ago
    Just like containers?.. I don't see how that's surprising or undesirable.
    - Vogtinator 3y ago
      Not necessary undesirable, but definitely surprising as it's a major change from the current behaviour.
insanitybit 3y ago
I can't imagine that root is any faster. It's just a lot easier to run things as root vs splitting out separate processes with their own isolation mechanisms. That the service runs as root isn't really the issue here. None of the attack relies on the abuse of some root capabilities, it's an authentication issue that abuses how the service works. Even if it were unprivileged somehow, this would still be the same impact.
paulddraper 3y ago
What VPN software doesn't run as root?
Bu9818 3y ago
Even with netns you'll need to run some parts as root, so you'll need to use privsep. Network namespaces are a really cool Linux feature, they're great for using multiple VPNs for different things. But for the average user, I'm not sure if netns has great integration with common desktop environments and it's on the user to make sure they don't accidentally run their program in the wrong/default network namespace.

Joker_vD 3y ago

Yeah, for some reason almost all user-specific customization of network-connectivity (VPN, DNS, etc) requires root privileges.

Vogtinator 3y ago
Yeah, because it affects networking in the entire system. If some pam session module were to set up its own network namespace that is shared by all user processes after login, this could be (mostly) solved. The result would be some surprising behaviour though, as processes outside have a possibly vastly different view of the network.
- Joker_vD 3y ago
  Just like containers?.. I don't see how that's surprising or undesirable.
  - Vogtinator 3y ago
    Not necessary undesirable, but definitely surprising as it's a major change from the current behaviour.

insanitybit 3y ago

I can't imagine that root is any faster. It's just a lot easier to run things as root vs splitting out separate processes with their own isolation mechanisms. That the service runs as root isn't really the issue here. None of the attack relies on the abuse of some root capabilities, it's an authentication issue that abuses how the service works. Even if it were unprivileged somehow, this would still be the same impact.

paulddraper 3y ago

What VPN software doesn't run as root?

Bu9818 3y ago

Even with netns you'll need to run some parts as root, so you'll need to use privsep. Network namespaces are a really cool Linux feature, they're great for using multiple VPNs for different things. But for the average user, I'm not sure if netns has great integration with common desktop environments and it's on the user to make sure they don't accidentally run their program in the wrong/default network namespace.