EnArtículo sobre endurecimiento de OpenVPN, se recomienda que el demonio del servidor elimine sus privilegios después del inicio en Linux:
OpenVPN ha sido diseñado con mucho cuidado para permitir que se eliminen los privilegios de root después de la inicialización, y esta característica siempre debe usarse en Linux/BSD/Solaris. Sin privilegios de root, un demonio de servidor OpenVPN en ejecución proporciona un objetivo mucho menos atractivo para un atacante.
Recomiendan que se establezcan las siguientes directivas:
user nobody
group nobody
lo que supongo significa que el demonio se ejecutará como nobodydespués de que se complete el inicio.
Sin embargo, hay varios archivos a los que OpenVPN accede en tiempo de ejecución,en particular el archivo CRL:
Cuando se utiliza la opción crl-verify en OpenVPN, el archivo CRL se volverá a leer cada vez que un nuevo cliente se conecte o un cliente existente renegocie la conexión SSL/TLS (de forma predeterminada, una vez por hora). Esto significa que puede actualizar el archivo CRL mientras se ejecuta el demonio del servidor OpenVPN y hacer que la nueva CRL entre en vigor inmediatamente para los clientes que se conectan recientemente.
Entonces, naturalmente, me preocupa si esas dos características son incompatibles: si el demonio pierde privilegios después del inicio, ¿cómo puede leer /etc/openvpn/server/crl.pem(propietario root:root, modo 0600; aplicación de SELinux) en tiempo de ejecución?
- Si el demonio no puede acceder al archivo CRL en tiempo de ejecución, ¿existe una buena manera de evitar este problema?
- Si el demonio puede acceder a los archivos CRL en tiempo de ejecución, me gustaría saber cómo es posible.
El sistema operativo es RHEL8.5 x86_64 en caso de que sea relevante.
Respuesta1
Como muchas aplicaciones que pierden privilegios, OpenVPN abre varios identificadores de archivos mientras todavía tiene root, que luego persisten. Una vez que haya perdido sus privilegios, el proceso aún podrá acceder a esos identificadores en el modo en el que se abrieron, mientras permanezcan abiertos.
Un compromiso del openvpnproceso no expondría el archivo a cambios en este caso, porque el archivo (probablemente, no lo he comprobado) está abierto como de solo lectura. Se necesitaría un nuevo identificador de archivo para abrirlo en modo de escritura, lo que fallaría porque el proceso ya no puede crear uno.