= 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 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'''||
||OpenVPN GUI||Interactive user||
||OpenVPN service||Privileged user||
||OpenVPN||Privileged user||

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 was suggested by Alon Bar-Lev.

= External links =

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