On Tuesday 28 February 2012 722:09:13 Carsten Krüger wrote: > DS> Heiko can probably give a much better answer, but if I remember right, > DS> the argument was this: Think of a multi-user setup (like a Terminal > DS> Server), the management interface will be accessible for all users on > DS> that server. > > a) Who an earth allows users on a terminal server to create VPN-sessions? > What happens if one of the sessions use redirect gateway? > All users are redirected?
That was actually an open question. I don't know if TS manages per session routing tables and haven't tried. However it was only an example and thus didn't have to make any practical sense. =) > I don't think that this is a valid point. The thing is that you need a second communication channel for requesting privileged operations. The management interface won't do, because the GUI (hopefully) runs with an unprivileged token. So the distinction between both is: * mgmt itf for interactive communication with the user * privilege channel for requesting operations that require elevation > Privilege seperation in openvnp deamon is nice, but is a complete > different thing than management interface access. It is, you got it right. > In openvpn case it should be something like this: > openvpnserv.exe running as a service, has no privileges and opens > management interface > openvpnhelpserv.exe running as a service has network operator rights > (no need for local system ...) > > openvpnserv and openvpnhelpserv could communicate via pipe. > > openvpn-management client (could be a perl script) connects to > management interface of openvpnserv.exe to start/stop a tunnel and > supply secrets. You forgot the GUI in this picture. If the service is connected to the management interface the GUI can't connect anymore. It need to to get things done, though. > DS> And how this is implemented, the OpenVPN Service will be started > DS> automatically. The GUI contacts the Service and the service starts the > DS> OpenVPN process with the privileges of the GUI user (IIRC, it was some > DS> neat Windows functions which allows to create processes with privileges > DS> based upon the user credentials of the other side of the named pipe). > > The sounds very bad. > The service shouldn't create processes in the name of the user. Interesting, could you elaborate? > DS> This service should be able to (for now only in theory; it has not been > DS> tested yet) handle more users simultaneously. > > Pretty useless, see above Not users, really. More like session. So you can connect to different server simultaneously. Of course this could be used by two different users at the same time or different impersonations in the same session, while still running ovpn with the credentials of the entity who started openvpn. So the point isn't really that many user can connect, but that the running sessions will be isolated from each other by the service. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
