Hi all, It's very good to have a discussion on this (though I'd do it on openvpn-devel) Sorry to butt in a little late, see my comments below
Jonathan K. Bullard wrote: > 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. > > > how would --cd and --nice considered "unsafe" . All that '--cd' does is "cd" to a directory . Similar for --nice (provided that you cannot *increase* the priority of the openvpn process >> 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. > OTOH: how many *clients* run the interface in bridged mode? that would be a very special (highly-advanced) use case in which the user hopefully knows what he is doing ... > 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. > > > 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. As Selva stated, --ifconfig* is needed to assign an IP address from the server to the client. Basically, without --ifconfig and --route you cannot set any IP address or route on the client. The approach I've been pondering for Windows in this case is to let the DHCP setitngs take care of all of them: - openvpn client receives IP info + routes from the server - client pushes this info to the tap-win32 adapter - windows picks up the settings from the tap-win32 adapter and applies them. No admin privileges needed at all (provided that the client has access to the tap-win adapter) BUT you cannot alter existing or default routes this way. AFAIK the Mac tun/tap driver does not include the DHCP mini-client but something similar could be added to the openvpn client software itself. Would such a setup work on MacOS ? --iroute is used solely on the server side inside a CCD file and hence should never be included/executed on a client JM2CW, JJK ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
