Changes between Version 6 and Version 7 of PrivilegeSeparation
- Timestamp:
- 03/12/12 13:52:47 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PrivilegeSeparation
v6 v7 1 = Introduction = 2 3 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. 4 5 = Use-cases = 1 = OpenVPN use-cases = 6 2 7 3 == Standalone workstations == 8 4 9 Standalone workstations and their VPN clients are controlled by the end-user. 5 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: 6 7 * Minimize damage a VPN client can do to the workstation if it's compromised 8 * What else? 10 9 11 10 == Enterprise workstations == 12 11 13 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.12 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: 14 13 15 For the VPN client this translates to the following requirements: 14 * Prevent a compromised VPN client being used by malware or remote attackers to access the enterprise network. 15 * What else? 16 16 17 * Non-privileges users can't read, copy or modify the VPN configuration 17 For the VPN client this translates to the following ''requirements'': 18 19 * Non-privileged users can't read, copy or modify the VPN configuration 18 20 * 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 19 21 … … 22 24 OpenVPN consists of several different, interacting components: 23 25 24 * ''TUN/TAP device:'' a virtual Ethernet interface 25 * ''OpenVPN:'' a tunneling daemon 26 * ''OpenVPN service:'' a system service wrapper for OpenVPN 27 * ''OpenVPN configuration files'' 28 * ''Network utilities:'' ifconfig, route, etc. 29 * ''OpenVPN GUI'': used by the interactive user to control OpenVPN 26 ||'''Component'''||'''Description'''||'''Executable?'''|| 27 ||Network utilities||ifconfig, route, etc.||Yes|| 28 ||OpenVPN||Tunneling daemon||Yes|| 29 ||OpenVPN service||System service wrapper||Yes|| 30 ||OpenVPN GUI||GUI for interactive users||Yes|| 31 ||OpenVPN configuration||Config files, keys, certificates, etc.||No|| 32 ||TUN/TAP interface||Virtual Ethernet interface||No|| 30 33 31 34 Each executable component runs as an ''operating system user'' with varying levels of privileges. Here we use the following terms: 32 35 33 * ''Interactive user''. This is the user account usedto log in to the operating system. Most end-user applications run as this user, so it should be granted as few privileges as possible.34 * ''Unprivileged user''. Any unprivileged user account. For example, on many Linuxes OpenVPN runs as such, usually ''nobody::nogroup''after initialization.36 * ''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. 37 * ''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. 35 38 * ''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. 36 39 37 40 Depending on the use-case, different levels of privileges are needed to satisfy all the requirements: 38 41 39 ||'''Component'''||'''Executable?'''||'''Standalone use-case'''||'''Enterprise use-case'''|| 40 ||Network utilities||Yes||Run by a privileged user||Run by a privileged user|| 41 ||OpenVPN||Yes||Run by the interactive user||Run by the OpenVPN user|| 42 ||OpenVPN service||Yes||Fill me||Fill me|| 43 ||OpenVPN GUI||Yes||Run by the interactive user||Run by the interactive user|| 44 ||OpenVPN configuration||No||Read/write by the interactive user||Read by OpenVPN, read/write by administrator|| 45 ||TUN/TAP||No||Access by the interactive user||Accessed by the OpenVPN user|| 42 = Practical privilege separation models (enterprise use-case) = 46 43 47 Only minimal privileges should be allocated. 48 49 = Practical solutions = 50 51 == Client/service separation model == 44 == GUI/service == 52 45 53 46 This solution was suggested by James Yonan. According to him it's fairly common in enterprise VPN clients: … … 55 48 ||'''Component'''||'''Runs as'''||'''Tasks/capabilities'''|| 56 49 ||OpenVPN GUI||Interactive user||Initiate connections and disconnections|| 57 ||OpenVPN service||Privileged user||Accept requests from the GUI and control OpenVPN||50 ||OpenVPN service||Privileged user||Accept connect/disconnect requests from the GUI. Control OpenVPN|| 58 51 ||OpenVPN||Privileged user||Setting up TUN/TAP interfaces, routes, making connections, etc.|| 59 52 60 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:53 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: 61 54 62 55 1. OpenVPN GUI makes an API call to the OpenVPN service 63 56 1. OpenVPN service asks OpenVPN to connect 64 57 1. OpenVPN connects 65 1. OpenVPN notifies OpenVPN service (?)66 1. OpenVPN service notifies OpenVPN GUI (?)58 1. OpenVPN notifies OpenVPN service that connection has been established(?) 59 1. OpenVPN service notifies OpenVPN GUI that connection has been established(?) 67 60 68 This separation model should not require any changes to current OpenVPN code, provided that local user does nothave administrator privileges.61 This separation model should not require any changes to current OpenVPN code, provided that local user does ''not'' have administrator privileges. 69 62 70 63 == Interactive service == 71 64 72 This approach [http://thread.gmane.org/gmane.network.openvpn.devel/5685/focus=5728 was suggested] by Heiko. 65 This approach [http://thread.gmane.org/gmane.network.openvpn.devel/5685/focus=5728 was suggested] by Heiko. At the moment the implementation is Windows-specific. 73 66 74 67 ||'''Component'''||'''Runs as'''||'''Tasks/capabilities'''|| 75 ||OpenVPN||Interactive user||Connect to the interactive service (for privileged operations)||76 ||Interactive service||Privileged user(?)||Fill me||77 68 ||OpenVPN GUI||Interactive user|||| 69 ||Interactive service||Privileged user||Act as a proxy between OpenVPN GUI and OpenVPN. Handles privileged operations on behalf of OpenVPN.|| 70 ||OpenVPN||Interactive user||Tunneling. Connect to the interactive service for privileged operations.|| 78 71 79 The interactive service is a new component that allows running privileged operations such changing routes from unprivileged OpenVPN/OpenVPN process. It's essentially a proxy the unprivileged OpenVPN/OpenVPN GUI application uses to do privileged operations. 72 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. 73 74 Implementation details: 80 75 81 76 == COM+ == … … 83 78 This approach [http://thread.gmane.org/gmane.network.openvpn.devel/5755/focus=5869 was suggested] by Alon Bar-Lev. See the [http://thread.gmane.org/gmane.network.openvpn.devel/5755/focus=5869 original email] for more detailed information. In a nutshell, privilege separation would be achieved using [http://en.wikipedia.org/wiki/COM%2B#COM.2B COM+] objects: 84 79 85 * OpenVPNUI.Network 86 * OpenVPNUI.Tunnel 80 ||'''Component'''||'''COM+ object'''||'''Runs as'''||'''Tasks/capabilities'''|| 81 ||OpenVPN GUI||-||Interactive user||Initiate connections and disconnections. Run OpenVPN connect/disconnect scripts|| 82 ||OpenVPN service||OpenVPNUI.Network||Privileged user||Create and remove routes|| 83 ||OpenVPN||OpenVPN.Tunnel||An unprivileged user account||Access OpenVPNUI.Network object|| 87 84 88 The identity and access to the se objects is controlled using the COM+ infrastructure. This means COM+ does all the work and no communication or security check within code are required.85 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. 89 86 90 ||'''Component'''||'''Runs as'''||'''Tasks/capabilities'''|| 91 ||OpenVPN||It's own unprivileged user account||Access OpenVPNUI.Network object|| 92 ||OpenVPN GUI||Interactive user||Initiate connections and disconnections. Run OpenVPN connect/disconnect scripts|| 87 Implementation details: 93 88 94 OpenVPNUI.Network COM+ object runs as a user belonging to the ''Network Configuration Operators'' group. The OpenVPNUI.Tunnel COM+ object has access to the OpenVPNUI.Network object, so that it can delegate privileged network operations to it. 95 96 In this configuration, only the administrator can modify OpenVPN configuration files. 89 * Something similar to Linux "ip" utility is needed for Windows (OpenVPNUI.Tunnel object) 97 90 98 91 = External links =