wiki:PrivilegeSeparation

Version 7 (modified by Samuli Seppänen, 12 years ago) (diff)

--

OpenVPN use-cases

Standalone workstations

Standalone workstations and their VPN clients are controlled by the end-user. As such, attempts to control the VPN client by the VPN server administrator are guaranteed to fail. The goals of privilege separation in this use-case are:

  • Minimize damage a VPN client can do to the workstation if it's compromised
  • What else?

Enterprise workstations

Enterprise workstations and their VPN clients are controlled by the enterprise system administrator(s). The system administrator's goal is to lock down client workstations as much as possible. The goals of privilege separation in this use-case are:

  • Prevent a compromised VPN client being used by malware or remote attackers to access the enterprise network.
  • What else?

For the VPN client this translates to the following requirements:

  • Non-privileged 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:

ComponentDescriptionExecutable?
Network utilitiesifconfig, route, etc.Yes
OpenVPNTunneling daemonYes
OpenVPN serviceSystem service wrapperYes
OpenVPN GUIGUI for interactive usersYes
OpenVPN configurationConfig files, keys, certificates, etc.No
TUN/TAP interfaceVirtual Ethernet interfaceNo

Each executable component runs as an operating system user with varying levels of privileges. Here we use the following terms:

  • Interactive user. This is the user account the end user uses to log in to the operating system. Most end-user applications run as this user, so it should be granted as few privileges as possible.
  • Unprivileged user. Any unprivileged user account. Not the same as the interactive user. For example, on many Linuxes OpenVPN runs as such, usually nobody::nogroup, after initialization.
  • Privileged user. Any user account that can do privileged operations. In OpenVPN context these operations are things such as 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:

Practical privilege separation models (enterprise use-case)

GUI/service

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

ComponentRuns asTasks/capabilities
OpenVPN GUIInteractive userInitiate connections and disconnections
OpenVPN servicePrivileged userAccept connect/disconnect requests from the GUI. Control OpenVPN
OpenVPNPrivileged userSetting 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. The privilege separation is handled by Windows Services. To clarify, this is what happens when the interactive user wants to connect:

  1. OpenVPN GUI makes an API call to the OpenVPN service
  2. OpenVPN service asks OpenVPN to connect
  3. OpenVPN connects
  4. OpenVPN notifies OpenVPN service that connection has been established(?)
  5. OpenVPN service notifies OpenVPN GUI that connection has been established(?)

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

Interactive service

This approach was suggested by Heiko. At the moment the implementation is Windows-specific.

ComponentRuns asTasks/capabilities
OpenVPN GUIInteractive user
Interactive servicePrivileged userAct as a proxy between OpenVPN GUI and OpenVPN. Handles privileged operations on behalf of OpenVPN.
OpenVPNInteractive userTunneling. Connect to the interactive service for privileged operations.

The interactive service is a new component that allows running privileged operations such changing routes by the unprivileged OpenVPN process. It's essentially a proxy the unprivileged OpenVPN/OpenVPN GUI application uses to do privileged operations.

Implementation details:

COM+

This approach was suggested by Alon Bar-Lev. See the original email for more detailed information. In a nutshell, privilege separation would be achieved using COM+ objects:

ComponentCOM+ objectRuns asTasks/capabilities
OpenVPN GUI-Interactive userInitiate connections and disconnections. Run OpenVPN connect/disconnect scripts
OpenVPN serviceOpenVPNUI.NetworkPrivileged userCreate and remove routes
OpenVPNOpenVPN.TunnelAn unprivileged user accountAccess OpenVPNUI.Network object

The identity and access to the COM+ objects would be controlled by the COM+ infrastructure. This means COM+ would do all the work and no communication or security check within code are required. Each component of OpenVPN could be started in a different security context, e.g. OpenVPN service would run within a context that allows Network configuration.

Implementation details:

  • Something similar to Linux "ip" utility is needed for Windows (OpenVPNUI.Tunnel object)

External links