On Wednesday 29 February 2012 11:38:17 Carsten Krüger wrote: > > You forgot the GUI in this picture. If the service is connected to the > > management interface the GUI can't connect anymore. > > ? > If I understand you correctly it works this way: > > openvpnserv.exe spawns openvpn.exe > openvpnhelperserv.exe spawns openvpnhelper.exe
It's completely different. =) There will be a new service, I called it interactive service. The GUI/client connects to a named pipe of that service. It passes the working directory, command line options and stdin input for openpvn to the service. The service impersonates the client, creates another named pipe and starts openvpn. Besides the stuff from the GUI it also passes to client end of the created pipe to openvpn. The GUI may now connect the the management interface. If openvpn needs to perform a privileged operation it request it through the named pipe that was passed by the interactive service. There's only a limited and well defined set of privileged operations that are serviced through the pipe. Currently only setting of IPv4 and IPv6 routes, but that will be extended to whatever makes sense e.g. ARP table flush is the next thing that will come. > > Not users, really. More like session. So you can connect to different > > server simultaneously. > > Yeah, that's a point. > But I think it would only need management commands like "connect vpn session > 1" "disconnect vpn session 1", "supply credentials for sessions 1". > Credentials could be more than username/password, for example tls key > or smartcard "connection". Again, the management interface is for user execution level related queries like give me you password, give me your certificate, give me your proxy settings (most of this is not implemented yet), while the privileged channel is for things that the user may not do. This is specifically tailored for the situation on Windows with the GUI. Don't know if it's usable by other system as much, i.e. NetworkManager is the mgmt client and root at the same time, however no ones holding them back to also pass a unix socket to openvpn and set the openvpn routes (etc.) directly instead of performing some sudo wrapper script magic or whatever is currently used. Again, this can be extended to the point where all privileged operation are performed through the unix socket. Binding to the listen socket may be an exception to that if the port is low or can one pass FDs through unix sockets? > > 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. > > hmm, I'm unsure if you would win something. > If the network communicating process is compromised (exploited from > internet) than it could get all the credentials via normal interface > from processes that holds them. The network communication process is openvpn and it has the rights as the user that started it. If that user has enough privileges to set it's primary token you have a very unfortunate setup, securitywise. 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
