80 | | * From James Yonan: ''"To be complete, the wrapper 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."'' |
81 | | |
| 80 | * Private key needs to be properly protected |
| 81 | * 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 | * The interactive service must not allow access from non-OpenVPN processes running as the same user as OpenVPN/OpenVPN GUI |
| 83 | * 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. |