O botão da VPN precisa de sudo: restrinja a regra, valide a política

O botão da VPN funciona para o administrador e falha para todos os outros, por isso alguém acrescenta uma linha ao sudoers. Essa linha costuma sobreviver ao problema que devia resolver e muitas vezes concede mais do que o botão precisa. Antes de editar a política, verifique se o proprietário suportado da ligação já consegue fazer o trabalho. As três condições abaixo decidem se o sudo está sequer envolvido.

Condição 1: o proprietário suportado consegue fazê-lo sem sudo

Na maioria dos ambientes Linux, o gestor de rede já é dono das ligações VPN, e a sua autorização passa pelo polkit e não pelo sudo. Um utilizador autorizado a levantar uma ligação pode fazê-lo a partir da linha de comandos sem qualquer regra de root. Verifique o que o gestor permite antes de assumir que o botão precisa de privilégio. Se a resposta for sim, a alteração no sudoers resolve um problema que não existe.

nmcli connection show
nmcli connection up "Work VPN"

Se o gestor recusar, leia por que motivo: uma regra do polkit em falta, uma ligação de outro utilizador ou um perfil guardado onde o utilizador não o consegue ler. Cada um destes tem uma correção suportada mais estreita do que uma regra de sudo. A escalada de privilégios é o último recurso, não o primeiro.

Condição 2: a regra nomeia um único executável e os seus argumentos

Se o sudo for realmente necessário, a regra deve nomear o comando exato e, sempre que possível, os argumentos que pode usar. Uma regra que deixa um utilizador executar um script de invólucro é apenas tão segura quanto as permissões desse script, porque o utilizador pode editar o que o root irá executar. Uma regra com um curinga depois do comando é o mesmo problema numa forma mais curta.

sudo -l -U alice
ls -l /usr/local/sbin/vpn-up

Verifique cada caminho na cadeia de comandos: o binário, o script que chama, o ficheiro de configuração que lê e qualquer diretório pelo meio. Se o utilizador puder escrever em qualquer um deles, a regra restrita é, na prática, root sem restrições. Os argumentos também contam, porque um comando que aceita um caminho de configuração pode ser apontado a um ficheiro que o utilizador controla. Escreva a regra para a operação, não para o botão.

Pare se o comando precisar de um ficheiro controlado pelo utilizador para funcionar. Nesse caso o desenho está errado, e nenhuma sintaxe do sudoers o tornará seguro.

Condição 3: toda a política é analisada, não só a sua linha

Valide com o editor que bloqueia o ficheiro e verifica a sintaxe, e valide a política montada em vez de um fragmento. Um ficheiro que é analisado sozinho ainda pode quebrar a ordem de inclusão ou duplicar uma regra de forma a alterar o comportamento.manual do visudo documenta tanto o editor com bloqueio como o modo apenas de verificação usado aqui.

sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher

A verificação indica o ficheiro e a linha quando falha, e esse relatório é a parte útil. Corrija a alteração pretendida através do editor em vez de forçar o salvamento de um erro conhecido, porque uma política quebrada pode bloquear todos os administradores de uma só vez. Os ficheiros no diretório de inclusão também precisam da propriedade e do modo exigidos pelo manual, ou serão ignorados ou rejeitados. A sintaxe é apenas a primeira porta: depois de a passar, releia a regra e pergunte o que ela permite de facto.

Pare se a única forma de a alteração funcionar é desativar a verificação de sintaxe. Isso não é uma política, é uma falha à espera de um reinício.

Recuperação: mantenha uma sessão que ainda funcione

Antes de guardar, garanta que já existe uma sessão administrativa autorizada aberta e que existe um segundo caminho para a máquina. Um erro no sudoers pode retirar-lhe a capacidade de o corrigir, e um botão na área de trabalho não vale esse risco. Se o sudo já estiver quebrado, use o caminho de recuperação documentado do sistema em vez de improvisar um.

sudo -n true
id

Alternativas como o pkexec dependem da sua própria instalação e política, por isso não são um segundo pedido de root garantido. Mantenha também a autorização local separada do fornecimento do segredo da VPN: uma regra de sudo não desbloqueia um agente de segredos ausente nem satisfaz o MFA da gateway. Após a correção, teste a conta normal executando apenas a operação pretendida e depois use os controlos habituais do gestor.

A decisão termina quando consegue dizer que condição justificou o sudo, o que a regra nomeia, que toda a política é analisada e como recuperaria se não fosse. Um lançador privilegiado que lhe custa o acesso administrativo é um mau negócio, e normalmente é evitável.