O seu comando VPN corre sem privilégios; o serviço não

O comando VPN corre como o seu utilizador, não aparece nenhuma palavra-passe e o túnel sobe. Essa sequência parece uma operação sem privilégios, e normalmente não é. Um serviço separado executa as alterações de rede, e a pergunta interessante é o que esse serviço fará por um chamador que não verificou. Contar pedidos de palavra-passe não lhe diz nada sobre essa fronteira.

A interface, o mecanismo e a verificação

A interface aceita pedidos: ligar, desligar, escolher um perfil. O mecanismo possui as operações de rede: criar interfaces, alterar rotas, aplicar filtros. A verificação de autorização decide se este chamador pode pedir esta ação. Os três podem estar repartidos por um binário, um auxiliar e um serviço de sistema, e o utilizador só vê o primeiro.

Os papéis podem viver num único binário, em dois processos ou num cliente e num serviço de sistema, e o comando que o utilizador vê raramente revela qual. Um ícone na bandeja e um daemon de sistema podem parecer uma só aplicação enquanto correm com uma autoridade muito diferente. O privilégio no momento da instalação e o privilégio no momento do pedido também são coisas diferentes. Um instalador que correu como root pode deixar um serviço à escuta de pedidos posteriores, muito depois de o gestor de pacotes ter terminado. É esse serviço, e não o comando que escreveu, que detém a autoridade.

Delegar é o desenho normal

Delegar o trabalho de rede com privilégios num serviço é a arquitetura razoável. Mantém as aplicações comuns sem privilégios e centraliza as operações que exigem cuidado. O desenho só compensa quando o serviço também verifica quem pede e para quê. Sem essa verificação é apenas uma porta mais larga.

O NetworkManager é o exemplo concreto no Linux. O seu guia de configuração explica como o PolicyKit autoriza pedidos que não são de root na configuração predefinida. Isso mostra autorização delegada num produto real. Não prova que todos os clientes comerciais usem o NetworkManager, nem descreve o caminho do socket ou a política de qualquer fornecedor concreto.

O padrão é delegação com uma política por trás. O exemplo é uma implementação desse padrão, não uma universal.

Leia a fronteira, não o pedido

Encontre o serviço, o dono da sua configuração e a interface local que o frontend usa. Depois pergunte que utilizadores podem pedir que operações. Poder subir e descer um perfil guardado não é a mesma permissão que carregar uma configuração que o operador nunca reviu. A diferença é toda a questão de segurança.

Comece pelo gestor de serviços e pela visão que o cliente tem das suas próprias permissões. Os comandos abaixo mostram se o daemon está a correr, o que o chamador lhe pode pedir e o que o daemon expõe sob o seu diretório de execução.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Pergunte também a que afeta a operação. Um item de menu que parece pessoal pode alterar rotas e DNS para toda a máquina, o que significa que pode perturbar as sessões de outros utilizadores. O raio de impacto pertence à mesma revisão que a permissão, e normalmente é ele que decide se o serviço precisa de um papel mais estreito.

Corrija as permissões da forma suportada

Tornar um socket de controlo protegido escrevível por todos, ou acrescentar uma conta a um grupo administrativo amplo, elimina um erro de permissão e cria um maior. O erro era a única coisa que lhe dizia que essa fronteira existia. Use o processo documentado de pertença ou autorização, incluindo a renovação de sessão que exige. A pertença a um grupo aplica-se muitas vezes apenas a novas sessões de início de sessão, e é por isso que uma alteração pode parecer não fazer nada até ao próximo início de sessão.

Se o produto expõe um papel mais estreito para a operação, prefira-o a uma concessão geral. Escreva o papel escolhido e o seu dono ao lado do nome do serviço.

Como é uma boa separação

As aplicações comuns ficam sem privilégios, o serviço executa apenas a preparação para que foi desenhado, e cada chamador é verificado contra uma política que alguém possui. É um desenho defensável. Também é auditável, porque a política tem um nome associado. Qualquer coisa maior merece uma exceção escrita em vez de uma alteração silenciosa de permissões.

O modo de falha é um serviço que executa qualquer pedido de qualquer utilizador local porque a interface é cómoda. Do lado do utilizador parece idêntico, e transporta uma autoridade muito maior. Teste um pedido recusado, não apenas o bem-sucedido. Uma recusa que vem da política é a prova de que a política existe.