O Perigo de um Software com Poderes Demais

Imagine que você abre um aplicativo de chat no seu computador. Ele parece inofensivo, certo? Mas, por padrão, esse programa tem os mesmos privilégios que você, o usuário. Se você tem uma chave privada de acesso ao servidor da sua empresa salva na sua pasta de documentos, esse chat também pode lê-la. Se houver uma falha de segurança nesse chat, um invasor pode dar ordens para que ele envie sua chave privada para um servidor externo. Quando falamos de Segurança em Go, o problema real não é apenas a falha no código, mas o fato de o programa ter acesso a algo que ele nunca deveria ter tocado. É aqui que entra o conceito de 'dropping privileges' (descarte de privilégios).

A Estratégia do Funil: Menos é Mais Segurança

O conceito central para garantir a Segurança em Go é o Princípio do Menor Privilégio. Ele dita que cada componente de um software deve ter apenas os privilégios necessários para realizar sua função e nada mais. O autor do material original utiliza uma metáfora fascinante para descrever esse processo de autolimentação:

"Como uma metáfora, pense em um lobisomem se acorrentando antes da lua cheia." — Autor do log.0x21.biz

A arquitetura de um software seguro deve funcionar como um funil invertido. O programa começa com todos os privilégios necessários para sua inicialização (como abrir uma porta de rede restrita), mas, à medida que avança para sua execução principal, ele vai descartando esses poderes. Uma vez que um privilégio é descartado, ele não pode ser recuperado. Se o programa nega a si mesmo o acesso ao sistema de arquivos, nenhum arquivo novo poderá ser aberto, mesmo que um hacker assuma o controle do processo posteriormente.

As Ferramentas de Contenção: Chroot e Troca de Usuário

Uma das formas clássicas de implementar a Segurança em Go é através do chroot. Essa técnica altera o diretório raiz do processo. Para o programa, o mundo passa a ser apenas uma pasta vazia ou limitada. Se ele tentar acessar arquivos confidenciais em outras pastas, o sistema operacional simplesmente dirá que esses arquivos não existem. No entanto, o chroot sozinho não é uma solução completa, pois um invasor persistente pode tentar escapar dessa 'prisão digital'.

Para reforçar essa segurança, o desenvolvedor pode usar as chamadas de sistema setuid ou setresuid. Elas permitem que o programa mude sua identidade de um usuário poderoso (como o 'root') para um usuário comum e sem privilégios. Em Go, isso exige cuidado: é preciso buscar as informações do usuário antes de entrar no chroot, caso contrário, o programa não conseguirá ler os arquivos de configuração de usuários do sistema.

Colocando um Orçamento de Recursos

Além de restringir o que o programa pode ver, a Segurança em Go também envolve restringir o quanto ele pode consumir. Ataques como o 'billion laughs' podem fazer um programa consumir 100% da CPU ou esgotar toda a memória RAM, travando o servidor. Através do setrlimit, o desenvolvedor pode definir limites rígidos:

• RLIMIT_CPU: Define o tempo máximo de processamento. Se o programa entrar em um loop infinito por causa de um ataque, o sistema o encerra automaticamente.
• RLIMIT_DATA: Limita a quantidade de memória que o programa pode alocar, evitando que ele derrube outros serviços no mesmo servidor.

O Poder do Pledge e do Unveil

Sistemas operacionais modernos como o OpenBSD oferecem ferramentas ainda mais elegantes, como o pledge e o unveil. Com o pledge, o programa faz uma 'promessa' ao sistema: 'Eu só vou usar a rede e ler arquivos'. Se ele tentar fazer qualquer outra coisa, o sistema o mata instantaneamente. Já o unveil permite criar uma lista branca de caminhos de arquivos que o programa pode acessar, bloqueando todo o resto. No Linux, o Seccomp BPF e o Landlock oferecem funcionalidades similares, permitindo filtrar quais comandos o programa pode enviar ao coração do sistema operacional (o kernel).

O Impacto Prático da Segurança em Go no Dia a Dia

Para o profissional brasileiro, aplicar essas técnicas de Segurança em Go significa construir softwares resilientes. Imagine um sistema de processamento de boletos. Se ele for 'algemado' corretamente, mesmo que um invasor descubra uma falha no parser de PDF, ele não conseguirá acessar o banco de dados de senhas ou usar o servidor para minerar criptomoedas, pois o programa terá descartado esses privilégios logo no início. Em resumo, a segurança não é apenas sobre não ter erros, mas sobre garantir que, quando o erro acontecer, o estrago seja o menor possível. Fonte: log.0x21.biz (https://log.0x21.biz/posts/go-privdrop/)

Fonte: log.0x21.biz