Sorry, forgot to cc: the list. ---------- Forwarded message ---------- From: Jonathan K. Bullard <jkbull...@gmail.com> Date: Wed, Dec 9, 2015 at 9:00 PM Subject: Re: [Openvpn-users] "Safe" configurations for installation without admin privileges? To: Selva Nair <selva.n...@gmail.com>
Thanks. Comments below, but tldr; I don't think my original approach will work. On Wed, Dec 9, 2015 at 6:35 PM, Selva Nair <selva.n...@gmail.com> wrote: > 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. Ah. Hadn't thought of the user specifying --remote (facepalm). Not allowing that is very restrictive, but allowing it opens a huge number of other problems. > 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. Yes, that's a prerequisite as far as I'm concerned. > 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.. > Are status, log and log-append unsafe? Yes. When OpenVPN is running as root they can write over any file, including system files (but not, on OS X 10.11, the "Security Integrity Protection" files, which is most of the important system files. > I would add > --down-pre, --up-restart, --chroot, --cd, --nice, --plugin Yes, thanks. > 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? Not my original idea, but an interesting approach. Whitelisting the user's safe override list might be possible but the more I think about it, I think it will be too restrictive to be useful. I describe a different approach below. > 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) Yes. Some are already disallowed by Tunnelblick. > 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. Yes : ( > --redirect-gateway and friends also may have to be frozen unless remote is > trusted and cannot be changed. Yes. > Does that mean --ca can be changed only by the admin? Yes. Tunnelblick makes the config file and all files referenced by it (including --ca files) read-only except by root. > There may be more concerns if the interface is bridged. Good point. Thank you for all of these comments. Lots to consider, but I think overall the "safe configurations" idea becomes either unsafe or not very useful. My original idea was that allowing the user to install "safe" configurations might be easier than one alternative I am considering, which is to allow Tunnelblick's "updatable configurations" to be replaced without admin approval. (They are controlled by the admin who set them up on Tunnelblick and are securely updated from servers specified in the (readable-by-root-only) configurations themselves that were set up by an admin. That's starting to look like a better, less complicated, more powerful alternative. Thanks again. Jon ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
