"Safe" configurations for installation without admin privileges?

[jkbull...gmail.com]

Inspired by Gert Doering (but don't blame him for any of my bad ideas : ), I'm considering adding a feature to Tunnelblick that would allow a standard user on a Mac to install "safe" OpenVPN client configurations without requiring administrator credentials. This would simplify administration of small VPN networks: a user could download a new configuration and install it without being an administrator of his/her computer. My question is: what would a "safe" configuration file look like?

Background: Tunnelblick launches OpenVPN as root and it usually stays running as root. To make sure that a standard user cannot use OpenVPN to obtain root access, Tunnelblick requires an administrator to authorize the "installation" of configurations. That installation involves creating a protected (writable only by root) copy of the configuration file and other files it references. At that point, the user cannot modify the configuration, so they can't get root access by, for example, adding or changing an --up script.

The idea is to allow installation of a configuration file as long as it doesn't contain certain options that could give the user access they should not have. Here is my initial list:

     --up
     --tls-verify
    --ipchange
    --client-connect
    --client-disconnect
    --route-up
    --route-pre-down
    --client-disconnect
    --down
    --learn-address
    --auth-user-pass-verify
    --config
    --write-pid
    --status
    --log
    --log-append
    --tmp-dir

(I created the above list from the OpenVPN 2.3 man page; I'll have to double-check it with the git-master code that processes options for the final list.)

Typical client configuration files do not contain any of those options. (Tunnelblick includes some scripts that are "safe" and are executed at the user's option. These --up and --down scripts do such things as process DNS changes and make it unnecessary to have --up and --down scripts in the client configuration file.)

I briefly considered using a "white list" of allowed options, and I may return to that, but there are so many options that would be a lot more typing : ) Using a blacklist is trickier, though, because I'd have to keep up with new options and add them to the blacklist as needed and failing to do so would result in a security vulnerability.

I'm not sure if I should also prohibit networking options such as:
    --ifconfig*
    --route
    --iroute
but am inclined to consider them "unsafe", too. They are usually "pushed" to the client, so that shouldn't affect many users.

Tunnelblick already enforces restrictions on the use of options such as --key and --ca to ensure that they do not access anything the user shouldn't; that would of course be done for these "safe" configurations, too.

Thoughts?

[Laas Toom]

Hi Jonathan,

Sorry, but I think this approach is wrong. It works against OpenVPN security model - proving herself sudo-capable, the user accepts all security risks and “vows” that she has looked at the config and scripts involved.

Essentially, what you are proposing is a setuid binary - OpenVPN is running as root, but then rather blindly accepts configuration from any user. Even a Flash exploit could end up executing OpenVPN and consider if you missed an option from your blacklist or any of the whitelist options has a bug in it. Setuid scripts must be as small as possible and do as little as possible.

Also as you already said - keeping the blacklist up to date is tedious and error-prone work with a lot at stake. I would not want to take it upon myself. :-)

Whitelisting might be more work up front, but a lot more secure. BTW, this is what Linux’s NetworkManager does - it has only a limited configuration GUI and does not load configuration from files at all. Any scripts must be placed in a root-writable directory to be executed.

An alternative approach would be a variant of:

https://community.openvpn.net/openvpn/wiki/UnprivilegedUser

That is - do not start OpenVPN as root at all, but add some necessary wrapping so that tap/tun devices and routes get created/dropped properly. This way, if user’s configuration contains some scripts, they are executed with the user’s privileges and it is up to the user to ensure that the scripts do their proper work (e.g. by placing some sudo-capability into them).

Best regards,
Laas

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

​

[jkbull...gmail.com]

Thanks, Laas.

This idea was pretty much shot down as either insecure or useless (my words, the posters were too polite) on the openvpn-users mailing list.

If you want to follow that discussion, which has much more, see https://sourceforge.net/p/openvpn/mailman/message/34683029/

Going to a scheme of having OpenVPN run as the user is a good idea and it is a long-term Tunnelblick goal, but it is beyond the scope of this (relatively minor) change.

On Thursday, December 10, 2015 at 2:45:24 AM UTC-5, Laas Toom wrote:

Hi Jonathan,

Sorry, but I think this approach is wrong. It works against OpenVPN security model - proving herself sudo-capable, the user accepts all security risks and “vows” that she has looked at the config and scripts involved.

Essentially, what you are proposing is a setuid binary - OpenVPN is running as root, but then rather blindly accepts configuration from any user. Even a Flash exploit could end up executing OpenVPN and consider if you missed an option from your blacklist or any of the whitelist options has a bug in it. Setuid scripts must be as small as possible and do as little as possible.

Also as you already said - keeping the blacklist up to date is tedious and error-prone work with a lot at stake. I would not want to take it upon myself. :-)

Whitelisting might be more work up front, but a lot more secure. BTW, this is what Linux’s NetworkManager does - it has only a limited configuration GUI and does not load configuration from files at all. Any scripts must be placed in a root-writable directory to be executed.

An alternative approach would be a variant of:

https://community.openvpn.net/openvpn/wiki/UnprivilegedUser

That is - do not start OpenVPN as root at all, but add some necessary wrapping so that tap/tun devices and routes get created/dropped properly. This way, if user’s configuration contains some scripts, they are executed with the user’s privileges and it is up to the user to ensure that the scripts do their proper work (e.g. by placing some sudo-capability into them).

Best regards,
Laas