openvpn-devel Mailing List for OpenVPN

On Sat, 24 Sep 2005, Mathias Sundman wrote: > On Sat, 24 Sep 2005, James Yonan wrote: > > > One of the interesting ramifications of this feature, is that it sets the > > stage for non-admin accounts to be able to run OpenVPN directly, without > > using the service wrapper. > > > > With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the > > TAP-Win32 device object required administrative privileges, and (b) if the > > server pushed routes, the client couldn't add them because adding routes > > on Windows requires privilege. > > > > This new release addresses (a). (b) is still an issue if the server is > > pushing routes. However (b) is less of an issue now since the "topology > > subnet" feature was added, because it allows a tun-based tunnel to operate > > without requiring any mandatory route pushes in order to function. Of > > course, if you are pushing custom routes, or are pushing > > "redirect-gateway" to clients, then those routes cannot be added if the > > user lacks administrative privileges (is there a finer-grained > > privilege that allows route modification without full admin privileges?). > > You're awesome! How did you solve it? Last time it was discussed on the > list I remember there was another way to open the TAP driver but it was a > non supported way and would probably not pass WHQL Driver tests so you > didn't want to use that method. Did you come up with an other solution, or > did you chose this way after all? Well as it goes, trying to solve intractable windows driver problems usually starts with the requisite tearing out of hair, followed by the transmission of a distress signal to microsoft.public.development.device.drivers: http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/f5baddd33208d68e/ff903d776234414c That gave me some ideas, such as using the ZwSetSecurityObject call on the device object after it has already been created with admin-only permissions. While the code for this seems reasonable, the ZwSetSecurityObject kernel call is not officially documented in the DDK, though I believe it's documented in another MS toolkit. I think the bottom line is that MS didn't really think this through, and we're going to have to wait until NDIS 6.0 (vista) to get an elegant solution. So while I'm not sure that using ZwSetSecurityObject would pass muster with the WHQL fashion police, my current sense is that it's a stable workaround. > Could we perhaps solve (b) in the TAP driver as well. I mean implement an > interface between userspace and the TAP driver that allows us to tell the > TAP driver to add/delete routes? That's tricky -- I'm sure that kernel space has some kind of API for route manipulation, I'm just not sure that it's documented. > Or do you still think the final solution is to run the whole openvpn > process via a service wrapper? > > The good thing with using the TAP driver also for adding routes is that > openvpn could continue running as a non-admin userspace application and > give us all the benefits of a potential security voulnerability found in > the openvpn code only beeing executed as non-admin. > > Of cource the same thing could be implemented in a seperate service module > only used for route additions and perhaps script execution. Right -- one could have a sort of "route" service. But when you start talking about script execution, then there's going to be a lot of security concerns, and I think you would end up with something that looks more like sudo. > The tricky part of cource would be how to control that only the openvpn > process is able to control the TAP driver or service module so we don't > allow normal users to execute arbitrary code as admin. I think making the TAP device object accessible from non-admin is reasonable from a security perspective. In fact, would argue that it actually improves security, in the same way that user/group nobody on *nix does. James 

On Sat, 24 Sep 2005, James Yonan wrote: > One of the interesting ramifications of this feature, is that it sets the > stage for non-admin accounts to be able to run OpenVPN directly, without > using the service wrapper. > > With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the > TAP-Win32 device object required administrative privileges, and (b) if the > server pushed routes, the client couldn't add them because adding routes > on Windows requires privilege. > > This new release addresses (a). (b) is still an issue if the server is > pushing routes. However (b) is less of an issue now since the "topology > subnet" feature was added, because it allows a tun-based tunnel to operate > without requiring any mandatory route pushes in order to function. Of > course, if you are pushing custom routes, or are pushing > "redirect-gateway" to clients, then those routes cannot be added if the > user lacks administrative privileges (is there a finer-grained > privilege that allows route modification without full admin privileges?). You're awesome! How did you solve it? Last time it was discussed on the list I remember there was another way to open the TAP driver but it was a non supported way and would probably not pass WHQL Driver tests so you didn't want to use that method. Did you come up with an other solution, or did you chose this way after all? Could we perhaps solve (b) in the TAP driver as well. I mean implement an interface between userspace and the TAP driver that allows us to tell the TAP driver to add/delete routes? Or do you still think the final solution is to run the whole openvpn process via a service wrapper? The good thing with using the TAP driver also for adding routes is that openvpn could continue running as a non-admin userspace application and give us all the benefits of a potential security voulnerability found in the openvpn code only beeing executed as non-admin. Of cource the same thing could be implemented in a seperate service module only used for route additions and perhaps script execution. The tricky part of cource would be how to control that only the openvpn process is able to control the TAP driver or service module so we don't allow normal users to execute arbitrary code as admin. Cheers - Mathias PS: Testing will come as well as a GUI version installation package! -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign OpenVPN GUI for Windows X NO HTML/RTF in e-mail http://openvpn.se/ / \ NO Word docs in e-mail 

This release is the latest in the topology branch which was first discussed here: http://openvpn.net/archive/openvpn-users/2005-09/msg00079.html Included in the Windows version of this release is a long-sought-after feature: The ability for OpenVPN to open the TAP-Win32 adapter from accounts other than administrator. Two methods of setting non-admin access are provided. The first method is implemented in the TAP-Win32 driver itself. By default, non-admin access is now allowed, however this can be turned off in the adapter advanced properties dialog, or in the OemWin2k.inf file. The second method configures non-admin access from userspace, using the new --allow-nonadmin standalone flag to the openvpn command. This method was more of a proof-of-concept, before I ported the code to the TAP-Win32 driver. I need people to test this new TAP-Win32 driver on as many Windows versions as possible (it is included in the pre-built Windows installer for this release). Of course, you should treat it as an early beta release, and not use it in production yet. I've tested the driver on XP SP2 only, and more testing is needed on Win2K and Server 2003. One of the interesting ramifications of this feature, is that it sets the stage for non-admin accounts to be able to run OpenVPN directly, without using the service wrapper. With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the TAP-Win32 device object required administrative privileges, and (b) if the server pushed routes, the client couldn't add them because adding routes on Windows requires privilege. This new release addresses (a). (b) is still an issue if the server is pushing routes. However (b) is less of an issue now since the "topology subnet" feature was added, because it allows a tun-based tunnel to operate without requiring any mandatory route pushes in order to function. Of course, if you are pushing custom routes, or are pushing "redirect-gateway" to clients, then those routes cannot be added if the user lacks administrative privileges (is there a finer-grained privilege that allows route modification without full admin privileges?). Testing is quite easy. Simply add this line to your "dev tun" based server config: topology subnet Download: http://openvpn.net/beta/to/ Change Log: 2005.09.23 -- Version 2.0.2-TO4 * Added feature to TAP-Win32 adapter to allow it to be opened from non-administrator mode. This feature is enabled by default, and can be enabled/disabled in the adapter advanced properties dialog. * Added --allow-nonadmin standalone option for Windows to set TAP adapter to allow non-admin access. This is a user-mode version of the code, and duplicates the same feature as the above entry. * Added fix that attempts to solve corner case of tunnel not forwarding packets when system clock is reset to an earlier time. * Added --redirect-gateway bypass-dns option. (Developers: To add bypass-dhcp or bypass-dns support to other OSes, add a get_bypass_addresses function to route.c for your OS.) * Added OPENVPN_PLUGIN_CLIENT_CONNECT_V2 plugin callback, which allows a client-connect plugin to return configuration text in memory, rather than via a file. * Fixed a bug where --mode server --proto tcp-server --cipher none operation could cause tunnel packet truncation. * openvpn --version will show [LZO1] or [LZO2], depending on version that was linked. James