auth-nocache com um ficheiro de credenciais: ajuda ou prejudica?

OpenVPN imprime no arranque um aviso que sugere auth-nocache, e a resposta tentadora é acrescentar a opção e ver a linha desaparecer. Esse conselho pressupõe um início de sessão interativo. Quando o nome de utilizador e a palavra-passe passam a viver num ficheiro, a comparação muda: a opção deixa de proteger a cópia duradoura e, num cliente que abdica de privilégios, pode quebrar a renegociação mais tarde. Vale a pena manter separados dois modelos de armazenamento antes de editar um perfil.

Duas formas de responder ao pedido de credenciais

O primeiro modelo é uma pessoa a escrever credenciais num terminal, ou uma interface de gestão que as guarda durante a sessão. O OpenVPN conserva essa cópia para poder responder à renegociação seguinte sem voltar a perguntar, e é exatamente disso que trata o aviso. Não há nada no disco envolvido, pelo que a única coisa a proteger é o processo que guarda o valor. Feche o cliente e a cópia desaparece com ele.

O segundo modelo é auth-user-pass a apontar para um ficheiro, onde o ficheiro é o armazém e o cliente o lê quando é preciso um valor. A exposição que importa aqui não é a memória do processo, mas as permissões e o proprietário desse ficheiro. O aviso de arranque vem das diretivas na configuração, não de uma inspeção da forma como fornece a palavra-passe, pelo que aparece nos dois modelos e não aponta para nenhum.

O resto desta comparação decorre dessa divisão: gestão da memória para um modelo, gestão do ficheiro e identidade do processo para o outro.

O que o auth-nocache descarta realmente

Com um início de sessão interativo, --auth-nocache remove a cópia guardada da memória depois de ter sido usada. O custo é um novo pedido em cada intervalo de renegociação, porque a ronda seguinte não pode reutilizar o que foi descartado.

Com um início de sessão baseado em ficheiro o cliente pode reler o ficheiro, pelo que o descarte é sobretudo invisível. Torna-se visível no único lugar onde as pessoas não o esperam: depois de o daemon abdicar de privilégios, se o ficheiro de credenciais não for legível pela conta com que agora corre.

Acrescente a opção porque compreende essa troca, não porque apareceu um aviso. Uma opção acrescentada para tornar um registo mais silencioso é uma opção cujo efeito ninguém mediu.

Onde o caminho baseado em ficheiro quebra

Um cliente que arranca como root para abrir o dispositivo de túnel e depois muda para user e group lê o ficheiro de credenciais duas vezes: uma antes da mudança, outra na renegociação que se segue. Se o ficheiro estiver no modo 600 e for de root, a segunda leitura falha, e a falha aparece uma hora depois como um erro de autenticação que parece um problema do servidor. Verifique o registo do cliente em torno do intervalo de renegociação e depois verifique a conta e o ficheiro em conjunto.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Ambas as linhas importam. A primeira diz-lhe quem pode ler o ficheiro, a segunda diz-lhe quem é realmente o daemon em execução, e uma discrepância entre as duas explica uma falha que nenhuma reescrita da palavra-passe corrigirá.

As correções práticas não são glamorosas: mova o ficheiro para um diretório e para um proprietário que a conta do daemon possa ler, ou mantenha a leitura privilegiada e confirme que o seu cliente só lê uma vez. Não resolva isto tornando o ficheiro legível por todos.

O caso que quer mesmo a opção

Um início de sessão com um código de utilização única quer auth-nocache por uma razão diferente. Um código de utilização única é gasto na primeira autenticação, pelo que uma cópia em cache é inútil na renegociação seguinte e um valor desatualizado poderia até ser reproduzido.

É uma questão sobre o tipo de credencial, não sobre onde é armazenada. Uma palavra-passe estática num ficheiro protegido tem o perfil oposto: tem de ser legível em cada renegociação, e a proteção de que precisa está no ficheiro.

Mantenha essas duas razões separadas nos comentários do perfil, senão o próximo administrador assumirá que a opção está ali pela razão que ele teria escolhido.

A comparação numa decisão

Escolha o modelo interativo quando há uma pessoa presente e a frescura importa, e aceite o pedido repetido como o seu custo. Escolha o modelo de ficheiro quando o cliente corre sem supervisão, e invista o esforço na propriedade, no modo e na abdicação de privilégios.

Nenhum dos modelos torna uma palavra-passe guardada segura por si só, e nenhum torna o aviso de arranque significativo.

Se o aviso for a única razão pela qual abriu o perfil, registe a decisão em vez de uma opção sem explicação: as credenciais vêm de um ficheiro que a conta do daemon pode ler, uma renegociação foi vista a ter sucesso, e a secção sobre renegociação do manual do OpenVPN 2.6 foi lida antes de alterar o seu intervalo. Essa nota sobrevive a qualquer sinalizador isolado.