EmArtigo de proteção do OpenVPN, é recomendado que o daemon do servidor elimine seus privilégios após a inicialização no Linux:
O OpenVPN foi projetado com muito cuidado para permitir que os privilégios de root sejam eliminados após a inicialização, e esse recurso deve sempre ser usado no Linux/BSD/Solaris. Sem privilégios de root, um daemon de servidor OpenVPN em execução fornece um alvo muito menos atraente para um invasor.
Eles recomendam que as seguintes diretrizes sejam definidas:
user nobody
group nobody
o que presumo significa que o daemon estará em execução nobodyapós a conclusão da inicialização.
No entanto, existem vários arquivos que o OpenVPN acessa em tempo de execução,notavelmente o arquivo CRL:
Quando a opção crl-verify é usada no OpenVPN, o arquivo CRL será relido sempre que um novo cliente se conectar ou um cliente existente renegociar a conexão SSL/TLS (por padrão, uma vez por hora). Isso significa que você pode atualizar o arquivo CRL enquanto o daemon do servidor OpenVPN está em execução e fazer com que a nova CRL entre em vigor imediatamente para clientes recém-conectados.
Então, naturalmente, estou preocupado se esses dois recursos são incompatíveis - se o daemon descartar privilégios após a inicialização, como ele poderá ler /etc/openvpn/server/crl.pem(owner root:root, mode 0600; SELinux enforcing) em tempo de execução?
- Se o daemon realmente não conseguir acessar o arquivo CRL em tempo de execução, existe uma boa maneira de contornar esse problema?
- Se o daemon puder acessar os arquivos CRL em tempo de execução, gostaria de saber como isso é possível.
O sistema operacional é RHEL8.5 x86_64, caso isso seja relevante.
Responder1
Como muitos aplicativos que eliminam privilégios, o OpenVPN abre vários identificadores de arquivo enquanto ainda tem root, que persiste. Depois de eliminar os privs, o processo ainda será capaz de acessar esses identificadores no modo em que foram abertos, enquanto permanecerem abertos.
Um comprometimento do openvpnprocesso não exporia o arquivo a alterações neste caso, porque o arquivo é (provavelmente, não verifiquei) aberto como somente leitura. Um novo identificador de arquivo seria necessário para abri-lo no modo de gravação, o que falharia porque o processo não poderia mais criar um.