Hi, On Wed, Dec 9, 2015 at 4:03 PM, Jonathan K. Bullard <jkbull...@gmail.com> wrote:
> Inspired by Gert Doering (but don't blame him for any of my bad ideas > : ), I'm considering adding a feature to Tunnelblick (a FOSS GUI for > OpenVPN on OS X) 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: > an 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? > This is a topic of wider interest, I believe. Separating options into safe and unsafe groups would very useful for a variety of reasons: for exmaple, what user defined directives may be safely honoured by the proposed interactive-service (or privilege separation) on windows. The conrcerns are somewhat different as the propoal is to run OpenVPN as user backed by a service as admin, but there are some common threads. I have been thinking about this, but comments below are some early thoughts. Also I presume that some remote ends could be potentially controllable by (or friendly to) the user and the user not to be given any privileges they already do not have. When implemented in the UI (as in the Tunnelblick case), a blacklist of options may become a maintanence nightmare. Whitelist may be a safer way. With a possibility for an admin to completely disable this feature during initial installation or later. Though a whitelist is better, it looks more useful to hammer-out a blacklist first, as you have done, so the rest follows that line of thought.. 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 > Are status, log and log-append unsafe? I would add --down-pre, --up-restart, --chroot, --cd, --nice, --plugin There will be too many banned options that will eventually cripple the config. So building the config from two pieces -- one specified by the admin and one user specified piece --- or let the user override certain options may be the way to implement this? Below I assume that is the approach considered. With that in view, more options to freeze in the config: --script-security, --remote and --server unless --secret or --ca (in tls mode) cannot be changed (more on that below) > > I'm not sure if I should also prohibit networking options such as: > --ifconfig* > --route > --iroute > If these are allowed, one is essentially making the underlying execs (route and ifconfig) setuid, though in a limited way, isn't it? Not sure of iroute, though.. > but am inclined to consider them "unsafe", too. They are usually > "pushed" to the client, so that shouldn't affect many users. > But how is pushed options safe? By installing a config with just --remote and a shared secret, a user could connect to some special end point and get any route pushed. So if user defined configs and pushed routes are allowed, then it essentially allows any route to be set up. Unless --server, --remote, --mode etc cannot be over-ridden by the user, or --secret and/or --ca are fixed. --redirect-gateway and friends also may have to be frozen unless remote is trusted and cannot be changed. > 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. > Does that mean --ca can be changed only by the admin? > > Thoughts? > There may be more concerns if the interface is bridged. Selva
------------------------------------------------------------------------------
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
