Changes between Version 9 and Version 10 of PrivilegeSeparation


Ignore:
Timestamp:
03/12/12 14:18:27 (12 years ago)
Author:
Samuli Seppänen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PrivilegeSeparation

    v9 v10  
     1[[TOC(inline, depth=1)]]
     2
    13= Introduction =
    24
    35This article attempts to gather all relevant information about OpenVPN privilege separation into one place. This includes use-cases, requirements, design and implementation details, etc. Currently this is very much work in progress. Please fill in the blanks and fix any errors.
     6
     7
     8OpenVPN consists of several different, interacting components:
     9
     10||'''Component'''||'''Description'''||'''Executable?'''||
     11||Network utilities||ifconfig, route, etc.||Yes||
     12||OpenVPN||Tunneling daemon||Yes||
     13||OpenVPN service||System service wrapper||Yes||
     14||OpenVPN GUI||GUI for interactive users||Yes||
     15||OpenVPN configuration||Config files, keys, certificates, etc.||No||
     16||TUN/TAP interface||Virtual Ethernet interface||No||
     17
     18Each executable component runs as an ''operating system user'' with varying levels of privileges. Here we use the following terms:
     19
     20 * ''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.
     21 * ''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.
     22 * ''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.
     23
     24Depending on the use-case, different levels of privileges are needed to satisfy all the requirements.
    425
    526= OpenVPN use-cases =
     
    2445 * 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
    2546
    26 = Privilege separation in different contexts =
    27 
    28 OpenVPN consists of several different, interacting components:
    29 
    30 ||'''Component'''||'''Description'''||'''Executable?'''||
    31 ||Network utilities||ifconfig, route, etc.||Yes||
    32 ||OpenVPN||Tunneling daemon||Yes||
    33 ||OpenVPN service||System service wrapper||Yes||
    34 ||OpenVPN GUI||GUI for interactive users||Yes||
    35 ||OpenVPN configuration||Config files, keys, certificates, etc.||No||
    36 ||TUN/TAP interface||Virtual Ethernet interface||No||
    37 
    38 Each executable component runs as an ''operating system user'' with varying levels of privileges. Here we use the following terms:
    39 
    40  * ''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.
    41  * ''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.
    42  * ''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.
    43 
    44 Depending on the use-case, different levels of privileges are needed to satisfy all the requirements:
    45 
    4647= Practical privilege separation models (enterprise use-case) =
    4748
     
    6566This separation model should not require any changes to current OpenVPN code, provided that local user does ''not'' have administrator privileges.
    6667
     68Details for successful implementation:
     69
     70 * Fill me
     71
    6772== Interactive service ==
    6873
     
    7681The 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.
    7782
    78 Implementation details:
     83Details for successful implementation:
    7984
    8085 * Private key needs to be properly protected
    8186  * From James Yonan: ''"To be complete, the wrapper [=interactive service] must also own the OpenVPN private key -- otherwise the configuration would be copyable by a non-privileged user, something that the enterprise model is determined to prevent.  Protecting the private key can be accomplished by storing the key in the system cert/key store, and accessing the key through a  Cryptographic Provider API such as Crypto API on Windows, PKCS!#11 on Linux, or Keychain on Mac."''
    8287 * The interactive service must not allow access from non-OpenVPN processes running as the same user as OpenVPN/OpenVPN GUI
     88  * From James Yonan: ''"...the pipe/socket to the privileged process [=interactive service] needs to be access-controlled so that only openvpn can use it.  You don't want to introduce a privilege escalation vulnerability where operations that would normally be privileged (like changing the default route) can now be done by any process in user space just by leveraging on the openvpn pipe/socket."''
    8389  * From James Yonan: ''"...other non-privileged software might be able to access the APIs for these wrappers [=interactive service], for example by pushing routes into the API. Malware that would normally be confined to user space can now perform privileged operations such as modifying the default route. The end user can now connect to any VPN  server of their choice (a major violation of enterprise model).  What you've essentially done with this model is introduce a privilege escalation vulnerability because operations that would normally require privilege, such as adding routes, can now be done by a non-privileged user.
    8490
     
    94100The 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.
    95101
    96 Implementation details:
     102Details for successful implementation:
    97103
    98104 * Something similar to Linux "ip" utility is needed for Windows (would run as the OpenVPNUI.Network COM+ object)