Hi, On Thu, Dec 10, 2015 at 4:10 AM, Jan Just Keijser <janj...@nikhef.nl> wrote:
> Hi all, > > It's very good to have a discussion on this (though I'd do it on > openvpn-devel) > Yeah, the -user list is getting more than a fair dose of technical talk these days. But this list has been quiet, a little more noise wont hurt, I hope. > Sorry to butt in a little late, see my comments below > > Jonathan K. Bullard wrote: > > Sorry, forgot to cc: the list. > > > [..] > > 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. > >> > > > > > >> 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 > That comment about --cd etc was in the context of my suggestion to have an admin-installed config and allow a non-admin user to update it. Only certain white-listed options to be merged-in. Then --cd is not safe to whitelist as that would allow the user to run virtually any script as root (provided there are some scripts specified in the original config). All this is based on the scenario that openvpn is running as root and the user has limited privileges. That's why --nice is unsafe to whitelist. Most users dont use advanced features etc are irrelevant here as the issue is what orders a privilaged process can safely take from a unprivileged user. Remember that the "user" may not be the friendly new hire, but an imposter who cracked into the user's account. [..] > > >> 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 ... > In fact the original topic concerned a kind of advanced use in a corporate environment: aka how to simplifiy life for lazy sysadmins with clueless users. In any case, the developer has to document unsafe use cases so that sysadmins can take note of it. The related topic of making openvpn safer by separating bulk of the code that could run as user and a small core (or service) as root may be somewhat different, but has related issues. One question would be what requests from a user's process are safe for the service to execute as root/admin. I think it will boil down to locking down most of the config. [..] > > > 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. > With that we are moving into the topic of running everything as user. This is very useful and is all that is required in some situations: for example, on our windows clients we do not redirect-gateway, nor do we need any static routes on other interfaces. There are some safety issues of allowing full user access to tun/tap, but not too severe as the default route cannot be changed. > 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. > Surely dhcp queries can be responded to from openvpn itself. But, even if tun interfaces pass-through DHCP discover (do they?), most dhcp-client softwares ignore layer 3 interfaces. I believe this was discussed on openvpn-devel ( -users?) a long time ago. Cheers, Selva
------------------------------------------------------------------------------
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
