SystemD que não vaza: NoNewPrivileges, ProtectSystem e PrivateTmp
Três flags que isolam serviços a custo zero. O que cada uma faz e quando ativar.
Quem usa systemd pra rodar serviço sem container Docker fica com a sensação de que falta isolamento. Container é fácil de raciocinar — namespace inteiro, sistema de arquivos próprio, network isolada. SystemD parece menos protegido. Mas systemd tem opções de hardening que, ativadas corretamente, oferecem segurança comparável à de container Docker, sem o overhead. Três opções fazem 80% do trabalho.
NoNewPrivileges=true desativa a habilidade do processo (e qualquer filho) de adquirir novas privilégios via setuid ou capabilities. Se o seu serviço foi explorado e o atacante tenta executar binário setuid pra escalar pra root, a syscall é bloqueada pelo kernel. Custa zero performance. Não tem razão pra não ligar em todo serviço de aplicação. A única ressalva é se você confia em algum binário no PATH que precisa de privilégio (raríssimo em código de aplicação).
ProtectSystem=full monta /usr, /boot, /efi como read-only pro processo. Tentativa de escrever em qualquer deles falha com EROFS. Isso impede que serviço comprometido instale backdoors no sistema. Custa zero performance, e em código de aplicação ninguém deveria escrever ali mesmo. ProtectSystem=strict é mais radical — torna /, /usr, /boot, /etc todos read-only. Pra serviço que só lê config e escreve em /var/log, strict é viável. Se serviço precisa escrever em /etc/cron.d ou similar, fica em full.
PrivateTmp=true cria um /tmp e /var/tmp privados pra processo. Outros processos do sistema não veem esses diretórios; outros usuários não conseguem ler nem escrever. Custa zero performance. Bloqueia tipo clássico de ataque onde dois serviços usam /tmp pra trocar dados sensíveis (logs temporários, arquivos de processamento). Liga em todo serviço da aplicação, sempre.
Outras opções que valem em camadas mais externas: ProtectHome=true (bloqueia /home, /root), ProtectKernelTunables=true (bloqueia /proc/sys), RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX (limita sockets). Cada uma adiciona robustez. Pra um servidor de aplicação Go ou Rust em produção, essa stack de flags cria isolamento real. Auditoria do CIS pra Debian recomenda todas, e quando você roda serviço sem essas configs e compara com mesmo binário em container Docker, percebe que o container era proteção desnecessária. SystemD bem configurado é sandbox suficiente.