= Introduction =

Much of this text is adapted from Alon Bar-Lev's [http://thread.gmane.org/gmane.network.openvpn.devel/5755 emails] to the openvpn-devel list, with many useful additions from James Yonan and other people.

= Use-cases =

== Standalone workstations ==

Standalone workstations and their VPN clients are controlled by the end-user.

== Enterprise workstations ==

Enterprise workstations and their VPN clients are controlled by the enterprise system administrator(s). The goal is to lock down client workstations as much as possible, so that a compromised client does not allow malware or remote attackers to access the enterprise network.

For the VPN client this translates to the following requirements:

 * Non-privileges users can't read, copy or modify the VPN configuration
 * Workstations can't have simultaneous access to an untrusted network (e.g. the public Internet) and the VPN network. If they did, malware could spread from the untrusted network to the enterprise network

= Privilege separation in different contexts =

OpenVPN consists of several different, interacting components:

 * ''TUN/TAP device:'' a virtual Ethernet interface
 * ''OpenVPN:'' a tunneling daemon
 * ''OpenVPN service:'' a system service wrapper for OpenVPN
 * ''OpenVPN configuration files'' 
 * ''Network utilities:'' ifconfig, route, etc.
 * ''OpenVPN GUI'': used by the interactive user to control OpenVPN

Each component can be isolated to run as an ''operating system user'' with varying levels of privileges. Here we use the following split:

 * ''Interactive user:'' a real human user with minimal privileges, should only run end-user applications (such as OpenVPN-GUI)
 * ''OpenVPN user:'' the user OpenVPN is running as (e.g. "nobody" on many Linuxes) 
 * ''Privileged user:'' the user doing privileged operations (e.g. adding routes or bringing up the TUN/TAP interface) 

Depending on the use-case, different levels of privileges are needed to satisfy all the requirements:

||'''Component'''||'''Standalone use-case'''||'''Enterprise use-case'''||
||TUN/TAP||Access by the interactive user||Accessed by the OpenVPN user||
||OpenVPN||Run by the interactive user||Run by the OpenVPN user||
||OpenVPN service||Fill me||Fill me||
||OpenVPN configuration||Read/write by the interactive user||Read by OpenVPN, read/write by administrator|| 
||Network utilities||Run by a privileged user||Run by a privileged user||
||OpenVPN GUI||Run by the interactive user||Run by the interactive user||

Only minimal privileges should be allocated.

= Practical solutions =

== Client/service separation model ==

This solution was suggested by James Yonan. According to him it's fairly common in enterprise VPN clients:

||'''Component'''||'''Runs as'''||'''Tasks/capabilities'''||
||OpenVPN GUI||Interactive user||Initiate connections and disconnections||
||OpenVPN service||Privileged user||Accept requests from the GUI and control OpenVPN||
||OpenVPN||Privileged user||Setting up TUN/TAP interfaces, routes, making connections, etc.||

Using this approach, ''OpenVPN service'' provides a simple API that the ''OpenVPN GUI'' uses to connect and disconnect. So, when the interactive user wants to connect, the following happens:

 1. OpenVPN GUI makes an API call to the OpenVPN service
 1. OpenVPN service asks OpenVPN to connect
 1. OpenVPN connects
 1. OpenVPN notifies OpenVPN service(?)
 1. OpenVPN service notifies OpenVPN GUI(?)

This separation model should not require any changes to current OpenVPN code, provided that local user does not have administrator privileges.

== COM+ ==

This approach [http://thread.gmane.org/gmane.network.openvpn.devel/5755/focus=5869 was suggested] by Alon Bar-Lev. See the [http://thread.gmane.org/gmane.network.openvpn.devel/5755/focus=5869 original email] for more detailed information. In a nutshell, privilege separation would be achieved using [http://en.wikipedia.org/wiki/COM%2B#COM.2B COM+] objects:

 * OpenVPNUI.Network
 * OpenVPNUI.Tunnel

The identity and access to these objects is controlled using the COM+ infrastructure. This means COM+ does all the work and no communication or security check within code are required.

||'''Component'''||'''Runs as'''||'''Tasks/capabilities'''||
||OpenVPN||It's own unprivileged user account||Access OpenVPNUI.Network object||
||OpenVPN GUI||Interactive user||Initiate connections and disconnections. Run OpenVPN connect/disconnect scripts||

OpenVPNUI.Network COM+ object runs as a user belonging to the ''Network Configuration Operators'' group. The OpenVPNUI.Tunnel COM+ object has access to the OpenVPNUI.Network object, so that it can delegate privileged network operations to it.

In this configuration, only the administrator can modify OpenVPN configuration files.

= External links =

 * [http://thread.gmane.org/gmane.network.openvpn.devel/5755 OpenVPN privilege separation (Windows)] (mailing list thread)