Hardening de serviços systemd: o que a pontuação de exposição não lhe diz

Execute systemd-analyze security numa máquina comum e obtém uma tabela de serviços com um número ao lado de cada um. É tentador ler esse número como um veredicto. A página de manual diz, em termos invulgarmente diretos, que não o é.

O que o comando mede realmente

O systemd-analyze security inspeciona as definições de segurança e de sandboxing das unidades de serviço. Se lhe for dado o nome de uma unidade, mostra uma análise detalhada; se não lhe for dado nenhum, inspeciona todas as unidades de serviço de longa duração atualmente carregadas e imprime uma tabela sucinta.

Atribui a cada definição relevante um exposure level (nível de exposição) numérico e depois calcula um valor global para a unidade. A documentação descreve isto como «uma estimativa no intervalo 0.0…10.0 que indica quão exposto está um serviço do ponto de vista da segurança». Os valores altos significam que foi aplicado muito pouco sandboxing. Os valores baixos significam sandboxing apertado e restrições fortes.

Até aqui isto lê-se como um scanner. A parte importante é a ressalva que se segue.

Os três limites que o manual afirma sem rodeios

Só vê aquilo que o próprio systemd implementa. A documentação é explícita: o comando «analisa apenas as funcionalidades de segurança por serviço que o próprio systemd implementa», o que significa que «quaisquer mecanismos de segurança adicionais aplicados pelo código do próprio serviço não são contabilizados». Um serviço que abdica dos privilégios internamente, se coloca a si próprio num chroot ou aplica o seu próprio filtro seccomp não recebe crédito nenhum.

Uma pontuação alta não significa vulnerável. Esta frase merece ser citada por inteiro, porque é aquela que as pessoas saltam: um exposure level alto «não significa nem que não haja sandboxing eficaz aplicado pelo código do próprio serviço, nem que o serviço esteja realmente vulnerável a ataques remotos ou locais». O que indica é que o serviço «poderá beneficiar de definições adicionais».

As definições isoladas podem ser desfeitas. O manual avisa que muitas definições de sandboxing «individualmente podem ser contornadas» se não forem combinadas com outras. Dá um caso concreto: um serviço que mantém o privilégio de estabelecer ou desfazer pontos de montagem pode anular a partir do seu próprio código muitas das outras opções de sandboxing. A ferramenta tem em conta algumas destas relações, mas a documentação diz claramente que não as contempla todas.

Porque é que «combinadas» é a palavra decisiva

Vale a pena determo-nos no exemplo dos pontos de montagem, porque muda a forma como deve ler os seus próprios resultados.

Se uma unidade puder manipular pontos de montagem, então as restrições expressas como visibilidade do sistema de ficheiros podem potencialmente ser revertidas pelo próprio serviço. A restrição continua declarada, e a pontuação continua a contá-la, mas o seu valor prático depende de haver outra definição presente ao seu lado.

É por isso que a abordagem por lista de verificação produz resultados dececionantes. Escolher as três diretivas que baixam a pontuação mais depressa pode deixar uma configuração que pontua bem e aguenta mal. A conclusão da própria documentação é que cada serviço deve usar «as definições de sandboxing e de segurança mais abrangentes e mais estritas possíveis», e não uma seleção delas.

Como usar a pontuação sem a interpretar mal

Uma leitura viável, coerente com aquilo que o manual reivindica para a ferramenta:

Trate-a como um inventário, não como uma auditoria. Diz-lhe quais as proteções ao nível do systemd que estão ausentes. Isso é genuinamente útil e é barato de obter. Não lhe diz se um serviço é seguro.

Compare-se consigo próprio ao longo do tempo. A utilização mais fiável é a deteção de regressões: uma unidade cujo exposure level sobe depois de uma atualização de pacote ou de uma alteração de configuração merece ser investigada. Essa comparação é significativa mesmo que o número absoluto não seja um veredicto.

Não ordene serviços de terceiros pela pontuação. Dois serviços com o mesmo número podem ter uma exposição real muito diferente, porque a ferramenta não consegue ver o sandboxing que um deles faz internamente. Ordená-los pela pontuação premiaria aquele que declara mais e castigaria aquele que faz mais.

Comece pelas unidades que são realmente alcançáveis. Um serviço exposto à rede com um exposure level alto é uma questão diferente de um temporizador local com o mesmo número. A pontuação não sabe qual é qual, e o leitor sabe.

O resumo honesto

O systemd-analyze security é uma boa ferramenta que se descreve a si própria com exatidão, o que é mais raro do que devia ser. Mede o sandboxing ao nível do systemd que declarou, numa escala de 0 a 10, e diz explicitamente que um número alto não é uma constatação de vulnerabilidade e que um número baixo não é um atestado de boa saúde.

Use-a para encontrar proteções em falta e para apanhar regressões. Combine definições em vez de escolher as mais baratas, já que o manual avisa que restrições isoladas podem ser desfeitas a partir do interior do serviço. E tenha presente que o número descreve a sua configuração, não a sua superfície de ataque.

Para a camada situada por baixo desta, o nosso guia de hardening de Linux cobre os parâmetros do kernel, o sysctl e o controlo de acesso obrigatório.

A descrição do comando, o intervalo de exposição de 0.0 a 10.0, os três limites declarados e o exemplo dos pontos de montagem são retirados da página de manual do systemd-analyze tal como é distribuída com o systemd 255. A redação e o comportamento podem mudar entre versões do systemd; consulte o manual da versão que está a executar. Este artigo não inclui qualquer amostra de saída do comando, porque o ambiente usado para o escrever não executa o systemd como PID 1, e inventar uma teria representado erradamente um resultado real.