In OpenVPN's hardening article, it is recommended that the server daemon drop its privileges after startup on Linux:
OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.
They recommend that the following directives be set:
user nobody
group nobody
which I assume mean that the daemon will be running as nobody after startup is complete.
However, there are several files that OpenVPN accesses at runtime, notably the CRL file:
When the crl-verify option is used in OpenVPN, the CRL file will be re-read any time a new client connects or an existing client renegotiates the SSL/TLS connection (by default once per hour). This means that you can update the CRL file while the OpenVPN server daemon is running, and have the new CRL take effect immediately for newly connecting clients.
So naturally I'm worrying if those two features are incompatible – if the daemon drops privileges after startup, how can it read /etc/openvpn/server/crl.pem (owner root:root, mode 0600; SELinux enforcing) at runtime?
- If the daemon is indeed unable to access the CRL file at runtime, is there a good way to circumvent this problem?
- If the daemon can access the CRL files at runtime, I would like to know how this is possible.
OS is RHEL8.5 x86_64 in case that's relevant.
Best Answer
Like a lot of applications that drop privileges, OpenVPN opens various file handles while it still has root, which then persist. Once it has dropped privs, the process is still able to access those handles in the mode they were opened with, for as long they remain open.
A compromise of the
openvpnprocess wouldn't expose the file to changes in this case, because the file is (likely, I haven't checked) opened read-only. A new file handle would be required to open it in write mode, which would fail as the process can no longer create one.