wiki:PrivilegeSeparation

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

--

Introduction

Much of this text is adapted from Alon Bar-Lev's 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:

ComponentStandalone use-caseEnterprise use-case
TUN/TAPAccess by the interactive userAccessed by the OpenVPN user
OpenVPNRun by the interactive userRun by the OpenVPN user
OpenVPN serviceFill meFill me
OpenVPN configurationRead/write by the interactive userRead by OpenVPN, read/write by administrator
Network utilitiesRun by a privileged userRun by a privileged user
OpenVPN GUIRun by the interactive userRun 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:

ComponentRuns as
OpenVPN GUIInteractive user
OpenVPN servicePrivileged user
OpenVPNPrivileged 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
  2. OpenVPN service asks OpenVPN to connect
  3. OpenVPN connects
  4. OpenVPN notifies OpenVPN service(?)
  5. 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