Porque o nosuid impede um auxiliar de VPN de se tornar root

Criptografia de disco e uma montagem nosuid soam como variações da mesma ideia, e não têm qualquer relação. Uma protege os dados em repouso, e a outra decide se o kernel respeitará um bit de privilégio no momento em que um programa arranca. Um auxiliar que não alcança a identidade que espera está a queixar-se da segunda. A suposição de que a primeira é a responsável leva as pessoas a reinstalar clientes que nunca estiveram avariados.

Duas Propriedades Sem Relação

A criptografia de disco responde a quem pode ler os blocos quando a máquina está desligada. Uma opção de montagem responde ao que o kernel fará com os bits de modo de um ficheiro quando alguém o executa. Nada da primeira limita a segunda, e um portátil totalmente criptografado pode montar um sistema de ficheiros com todas as restrições no lugar.

Lê-las como uma única propriedade é o que produz a teoria de que uma pasta pessoal criptografada impede o acesso de root. Essa teoria sobrevive porque os dois sintomas aparecem na mesma máquina, não porque partilhem uma causa.

O Que Suprime Realmente a Transição

A referência do execve descreve como um executável com set-user-ID altera a identidade efetiva do novo processo para a do proprietário do ficheiro. A mesma página enumera as condições que suprimem essa transição e a equivalente para os identificadores de grupo: uma definição no_new_privs, um sistema de ficheiros montado com nosuid e um processo a ser seguido. As capacidades do ficheiro são ignoradas nas mesmas condições. Essas quatro regras cobrem quase todos os relatos deste tipo.

Essa lista explica porque o modo impresso pelo ls nunca é toda a história da autorização. Não diz qual condição causou uma mensagem de falha concreta, e a aplicação pode estar a relatar uma operação de credenciais não relacionada com as mesmas palavras. Anote o programa exato, o lançador e a sequência de erros antes de tirar uma conclusão.

Identifique o executável instalado pelo pacote suportado, o seu proprietário, o seu caminho real e a política do sistema de ficheiros que o contém. Uma cópia numa pasta de transferências não é o auxiliar instalado, diga o que disser o seu modo.

O Que Não Fazer

Colocar bits set-user-ID num binário não verificado e movê-lo até a restrição desaparecer não é uma reparação. Substitui uma política que não compreendia por um privilégio que não pode auditar, e a mesma técnica aplicada a um auxiliar é uma via de escalada bem conhecida. Retirar o nosuid de uma montagem é pior, porque afeta todos os programas desse sistema de ficheiros, não apenas um.

A via suportada é a instalação documentada do auxiliar ou do serviço pelo cliente, realizada por um administrador, que coloca o binário onde a política o espera. Assim mantém-se um único mecanismo de privilégio em vez de dois.

Confirme o Contexto de Arranque Real

Após uma correção autorizada, execute o auxiliar como o produto o executa e não a partir de uma shell de root. Um sucesso como root não prova nada sobre o caminho de um utilizador comum, e a diferença entre esses dois contextos é exatamente aquilo de que tratava a falha.

Depois confirme a operação de rede para a qual o auxiliar existe. Um auxiliar que arranca mas não consegue configurar a interface deslocou o problema uma etapa, não o resolveu.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

Anote as opções de montagem e a propriedade do auxiliar na mesma nota. Caso contrário, a próxima pessoa que depurar isto repetirá a teoria da criptografia desde o início.