O console é um privilégio: por que ele pede a própria permissão

Um console parece uma tela. Você abre, surge uma janela, texto corre dentro dela. Dá a sensação de "só estou olhando".

Só que um console é um shell. E o shell do servidor é o direito mais alto que existe naquela máquina.

Dois poderes distintos

Mudar configurações. Você pode fazer o que a interface permite. Os limites são claros, porque quem os traça é a interface.

Abrir um shell. Você pode fazer qualquer coisa. Inclusive o que a interface recusaria e o que a interface nunca ouviu falar.

Esses dois poderes não contêm um ao outro. Ter um não exige o outro e, mais importante: conceder um não deveria significar conceder o outro.

A distinção é real e aparece nos papéis embutidos

O Proxmox liga o console à permissão própria dele, não à permissão geral de "pode mudar". Dá para ver que isso é real nos papéis embutidos: o papel de administrador de sistema carrega os direitos de auditoria, console e registro e não contém o direito de mudança.

Ou seja, é uma configuração legítima dar a alguém o direito de abrir um console sem o direito de mudar configurações. E o contrário também.

A situação comum que torna isso importante

O Proxmox permite criar papéis personalizados, e um papel assim é muito comum: um operador que pode mudar as configurações de rede mas não deve alcançar o shell do servidor.

É um pedido razoável. Editar a configuração de rede e rodar qualquer comando no servidor não são a mesma coisa.

Mas se um produto raciocina "se pode mudar, também pode abrir o console", ele entrega a esse operador um shell de root sem perceber. Ele consegue pelo painel o que não conseguiria no Proxmox.

O princípio geral que decorre disso

Um modelo de permissões precisa copiar a definição da própria plataforma, não parafraseá-la.

Um portão que diz "mais ou menos a mesma coisa" funciona certo nas instalações comuns e ninguém percebe. A brecha se abre no dia em que um papel incomum é criado. E quando esse dia chega, ninguém lembra de uma aproximação escrita anos antes.

A mesma régua vale para o acesso a arquivos

Mais um detalhe, porque costuma passar batido: o acesso ao sistema de arquivos do servidor equivale a um shell mesmo sendo só de leitura.

O motivo é simples: arquivos de senha, chaves e segredos do cluster ficam nesse sistema de arquivos. Quem tem direito só de leitura mas consegue ler arquivos já pode descobrir tudo.

Então o acesso a arquivos não pode ser concedido com um direito de "olhar"; ele exige a mesma régua de um shell.

O que o Atlas faz

No Atlas, o console, o shell remoto e o acesso a arquivos estão ligados somente à permissão de console. O direito de mudança sozinho não abre essas superfícies.

Nem sempre foi assim, e o artigo precisa terminar com honestidade: antes essas superfícies aceitavam também o direito de mudança. O comentário no código dizia a coisa certa, dizia "o equivalente é a permissão de console", mas o código fazia outra coisa.

Isso foi descoberto medindo contra a definição do próprio Proxmox, e foi corrigido. O resultado da medição foi claro: o Proxmox liga o shell somente à permissão de console e não aceita o direito de mudança.

O peso real também precisa ser dito como é: não era explorável com papéis embutidos, porque o único papel embutido que contém o direito de mudança tem também a permissão de console. O risco estava nos papéis personalizados, ou seja, no exemplo do operador de rede descrito acima.

A lição que decorre vale também para o próprio produto: um comentário estar certo não significa que o código esteja. Os dois precisam ser medidos separadamente.