Resumo

  • No modelo privilegiado do Postfix, a maioria dos serviços abre os arquivos necessários e depois abandona root antes de atender solicitações; quatro agentes de entrega mantêm uma identidade root salva para tarefas delimitadas.
  • O master sem privilégios reduz os direitos do supervisor, mas enfraquece a separação interna, amplia o acesso a chaves e registros quando um serviço é comprometido e só é admitido em um conjunto restrito de configurações de produção.

Perguntar se um servidor de e-mail “roda como root” diz pouco sobre onde está o risco. A arquitetura do Postfix sugere perguntas mais úteis: qual processo precisa de qual privilégio, em que etapa de uma solicitação e sobre quais arquivos ou recursos pertencentes a outros usuários?

Uma mensagem recebida por SMTP ou QMQP chega primeiro a um serviço exposto à rede. Ele verifica a entrada e passa o envelope e o conteúdo a cleanup(8). Essa etapa realiza o processamento final antes de enfileirar, grava a mensagem na fila de entrada e avisa qmgr(8). O gerenciador escolhe os agentes que farão a entrega. A fila ativa tem um limite, de modo que um grande acúmulo de mensagens não obriga o processo a abrir todas elas de uma vez. O master(8), que permanece residente, supervisiona os serviços, inicia processos sob demanda e aplica os limites configurados.

Supervisor e agentes que atendem solicitações não fazem o mesmo trabalho. No modelo Postfix com master privilegiado, um serviço pode iniciar com root, abrir arquivos sensíveis — como chaves privadas TLS ou senhas de banco de dados — e abandonar root de forma irrevogável antes de processar solicitações. A documentação de segurança afirma que um serviço comprometido depois dessa queda não consegue mais abrir esses arquivos, bancos de dados ou registros. Root é usado durante a inicialização e a seleção de privilégios; isso não significa que cada processo acessível pela rede continue com root durante toda a sua vida.

Há exceções. A maioria dos serviços abandona root definitivamente, mas local(8), pipe(8), spawn(8) e virtual(8) mantêm uma identidade efetiva root salva. Eles precisam dela para atuar como o usuário de destino ou acessar recursos que não pertencem ao Postfix, como uma caixa postal ou um comando externo. O projeto distingue duas funções: root pode separar os privilégios entre serviços Postfix e pode confinar o Postfix quando um serviço atravessa para arquivos de usuários ou programas externos. A expressão genérica “processo root” esconde essas fronteiras diferentes.

Em uma apresentação na conferência LISA de 2010, Wietse Venema descreveu o Postfix como uma arquitetura particionada de privilégio mínimo. Ele apontou como influência um desenho de firewall que separava o recebimento e a entrega de e-mail com processos de baixo privilégio em chroot. Também explicou por que programas pequenos ajudam na manutenção depois que a infraestrutura de comunicação está construída. Esse relato registra como o autor entendia o desenho naquele momento; não informa a quantidade atual de daemons nem mede resultados de segurança.

A documentação vigente descreve a divisão operacional entre recebimento, limpeza, gerenciamento de filas e entrega.

A mudança recente não afirma que retirar root do supervisor torna automaticamente o sistema todo mais seguro. Segundo a documentação do Postfix, Venema implementou o master(8) sem privilégios em 2025, inicialmente para testes de integração não publicados. Depois de uma consulta de cliente em 2026, ele adaptou a implementação para uso limitado em produção e acrescentou documentação. Nesse modo, o master opera com a identidade fixa postfix, em vez de root. Os serviços usam os mesmos privilégios Postfix durante a inicialização e ao processar solicitações. O projeto diz que isso impede manter a separação interna de privilégios e o confinamento usual para acesso a arquivos externos ao Postfix, entrega em caixas postais e execução de comandos de terceiros.

A diferença aparece nas permissões. Os arquivos de chaves secretas do Postfix precisam ser legíveis pelo usuário postfix; se um serviço for comprometido, poderá ler essas chaves. Os registros opcionais do Postfix precisam pertencer a postfix, o que permite a um serviço comprometido consultá-los, alterá-los ou apagá-los. Os arquivos de configuração não podem pertencer ao usuário postfix. Em instalações com várias instâncias, todas precisam usar master privilegiado ou todas precisam usar master sem privilégios; os modos não podem se misturar.

O limite de produção é estreito. A documentação permite o master sem privilégios em implantações que encaminham todas as mensagens por SMTP ou LMTP. Ela proíbe o uso em produção quando serviços locais podem executar programas externos ao Postfix ou entregar mensagens em arquivos de caixa postal. Um risco citado é que um comando no arquivo .forward de um usuário rode com privilégios postfix, em vez dos privilégios do destinatário, permitindo que o usuário controle o sistema de e-mail. O alerta se refere a configurações específicas, mas não deixa margem para dúvida.

A lição arquitetônica não é “root é seguro” nem “root é inseguro”. Mudar as permissões desloca o risco entre fronteiras. Um master sem root pode servir a um relay limitado, mas seus serviços passam a compartilhar o acesso a chaves e registros que o modelo privilegiado consegue manter separados após a inicialização e a queda de privilégios. Antes de trocar a identidade do master, os operadores precisam mapear os caminhos de entrega e verificar se o modo escolhido corresponde aos arquivos e comandos acessíveis a cada serviço.

A documentação pública define a troca; não mostra qual modo é mais frequente nem quais resultados de segurança ocorrem em instalações reais.

Fontes