Changes between Version 9 and Version 10 of PrivilegeSeparation
- Timestamp:
- 03/12/12 14:18:27 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PrivilegeSeparation
v9 v10 1 [[TOC(inline, depth=1)]] 2 1 3 = Introduction = 2 4 3 5 This 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 8 OpenVPN 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 18 Each 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 24 Depending on the use-case, different levels of privileges are needed to satisfy all the requirements. 4 25 5 26 = OpenVPN use-cases = … … 24 45 * 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 25 46 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 46 47 = Practical privilege separation models (enterprise use-case) = 47 48 … … 65 66 This separation model should not require any changes to current OpenVPN code, provided that local user does ''not'' have administrator privileges. 66 67 68 Details for successful implementation: 69 70 * Fill me 71 67 72 == Interactive service == 68 73 … … 76 81 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. 77 82 78 Implementation details:83 Details for successful implementation: 79 84 80 85 * Private key needs to be properly protected 81 86 * 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."'' 82 87 * 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."'' 83 89 * 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. 84 90 … … 94 100 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. 95 101 96 Implementation details:102 Details for successful implementation: 97 103 98 104 * Something similar to Linux "ip" utility is needed for Windows (would run as the OpenVPNUI.Network COM+ object)