Sandbox de Aplicacoes no Linux com Bubblewrap, Firejail e Flatpak

Um pesquisador da equipe Basilisk abriu um PDF de bug bounty no Evince e, trinta segundos depois, o auditd registrou uma tentativa de leitura em ~/.ssh/id_ed25519. O processo nao tinha motivo nenhum para tocar naquele diretorio, mas tocou. Esse incidente, que terminou bem porque o Evince rodava dentro de um perfil Bubblewrap restrito, e a razao deste post existir. Sandbox em desktop Linux nao e teatro de seguranca: e a camada que separa um exploit chato de uma exfiltracao silenciosa de chaves SSH, tokens de cloud e cookies de sessao. Vamos aterrissar Bubblewrap, Firejail e Flatpak com perfis testados em producao OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal.

Por que o desktop e o verdadeiro alvo

Servidores sao endurecidos, o desktop e esquecido, e no entanto o que tem valor vive exatamente ali: chaves SSH, sessoes de navegador, tokens de cloud, senhas salvas e dados de cliente. Um unico exploit de renderizacao em navegador, leitor de PDF ou suite de escritorio basta para rodar com os seus privilegios de usuario. Sem sandbox, 'com privilegios de usuario' significa acesso total a todo o seu $HOME. O objetivo do sandbox nao e impedir todo exploit, mas encolher o raio de um bem-sucedido ate que ele nao alcance nada que valha a pena.

O mecanismo por baixo sao os namespaces do Linux e os filtros seccomp, que dizem ao kernel quais arquivos, redes, processos e syscalls um processo pode sequer ver. Bubblewrap, Firejail e Flatpak sao tres niveis de conveniencia sobre as mesmas primitivas do kernel. Se voce entende as primitivas, configura os tres com intencao em vez de copiar e colar.

Bubblewrap: a base

Bubblewrap (bwrap) e a base. Ele e o unprivileged container runtime que o Flatpak usa por baixo dos panos, distribuido pelo projeto containers e auditavel em poucas centenas de linhas de C. Um perfil minimo para abrir PDFs ficaria assim: bwrap --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev --tmpfs /tmp --bind ~/Downloads/sandbox-pdf /home/user --unshare-all --share-net /usr/bin/zathura arquivo.pdf. Note o --unshare-all seguido de --share-net apenas se necessario, e o bind de um diretorio especifico em vez do $HOME inteiro. Esse padrao de allow-list e o que difere sandbox real de placebo e combina muito bem com investigacoes de DFIR DFIR no Linux: Triagem ao Vivo com UAC e Velociraptor.

O ponto decisivo e a postura default-deny: voce monta exatamente o que o processo precisa, e todo o resto nao existe para ele. Um leitor de PDF nao precisa de rede, entao tire o --share-net; ele nao precisa de ~/.ssh, entao esse caminho nunca aparece na arvore montada. Cada bind que voce deixa de fora e uma porta que o exploit sequer enxerga.

Firejail: perfis prontos para o dia a dia

Firejail e mais alto nivel e vem com aproximadamente 1.000 perfis prontos em /etc/firejail. Para uso diario em estacao de pesquisador, o trio firefox.profile, thunderbird.profile e libreoffice.profile resolve 80 por cento da superficie de ataque. Comece com firejail --profile=/etc/firejail/firefox.profile --private-tmp --dns=9.9.9.9 firefox. Habilite AppArmor com firejail --apparmor e cheque o status com firejail --list. O calcanhar de Aquiles historico do Firejail e o binario SUID; se isso te incomoda, instale com setcap cap_sys_admin+ep em kernels recentes ou migre para Bubblewrap puro. Para abrir docs suspeitos de phishing, combine com higiene de metadados antes de qualquer reencaminhamento Higiene de Metadados: Limpando EXIF, PDF e Office antes de Publicar.

Firejail e o caminho mais rapido para seguranca de verdade porque os perfis ja existem e sao mantidos. O preco e o binario SUID, que e parte da superficie de ataque em si. Para a maioria dos pesquisadores o trade-off e aceitavel; para os threat models mais duros, Bubblewrap puro sem SUID ganha.

Flatpak: permissoes declarativas e Flatseal

Flatpak entrega aplicacoes empacotadas com manifesto declarativo de permissoes. O comando que voce quer memorizar e flatpak override --user --nofilesystem=home org.mozilla.firefox seguido de flatpak override --user --filesystem=~/Downloads org.mozilla.firefox. Isso revoga acesso ao $HOME inteiro e devolve apenas Downloads. Para auditar o que cada app pede, use flatpak info --show-permissions org.telegram.desktop ou abra Flatseal. Aplicacoes como Zoom, Slack e Discord rodando via Flatpak com --nofilesystem=host e --nodevice=all reduzem drasticamente o estrago de uma CVE de renderizacao. Isso encaixa direto em hardening de estacoes de trabalho de alto risco Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao.

O erro mais comum e confiar que Flatpak sozinho ja e seguro. Muitas apps vem com permissoes padrao amplas como filesystem=home ou talk-name=org.freedesktop.Flatpak, que dissolvem a sandbox na pratica. Revise cada app instalada uma vez com o Flatseal e revogue sistematicamente o que ela nao precisa; o manifesto e a oferta do desenvolvedor, nao uma garantia de seguranca.

Cenarios praticos na Basilisk

Cenarios praticos que rodamos na Basilisk: analise de amostra recebida por cliente fica em VM dedicada com Remnux, nao em sandbox de desktop Analise de Malware em Lab Isolado: Setup Seguro com FlareVM e Remnux. Mas leitura de PDF de relatorio, abertura de docx de cliente, navegacao em sites de bug bounty e teste de extensao de navegador acontecem todos em perfis Bubblewrap com namespace de rede separado via slirp4netns. Para clientes que exigem comunicacao por Signal Desktop, rodamos a versao Flatpak com --nofilesystem=home --filesystem=xdg-download e MFA por hardware token passado via --device=all so durante o pareamento OPSEC de Comunicacao: Signal, SimpleX e Session Comparados Tecnicamente. Cada perfil vive em git, revisado em pull request, exatamente como codigo de producao.

A linha entre sandbox e VM e uma linha de ameaca. Codigo nao confiavel que vai de fato executar entra numa VM descartavel com sua propria fronteira de kernel. Apps confiaveis que renderizam input potencialmente hostil entram numa sandbox de desktop. Misturar os dois significa ou abrir uma amostra de malware no seu desktop ou inflar cada clique de PDF numa VM inteira.

Namespaces e seccomp: o que protege por baixo

Sob as tres ferramentas estao as mesmas primitivas do kernel. Os namespaces de user, mount, PID, rede e IPC isolam o que o processo enxerga do sistema e de outros processos. O seccomp-bpf filtra as syscalls permitidas e com isso encolhe a superficie de ataque do kernel sobre a qual um escape poderia se apoiar. Um perfil seccomp apertado e a diferenca entre um bug de renderizacao que morre na sandbox e um que escapa por uma cadeia exotica de syscalls.

Voce nao precisa escrever filtros na mao, mas deveria entender que o --unshare-all configura os namespaces e que Firejail e Flatpak trazem defaults seccomp razoaveis. Quando uma app quebra, diagnostique com strace qual syscall ou caminho falta e abra so aquele, em vez de afrouxar a sandbox inteira.

Tres armadilhas comuns

Tres armadilhas comuns. Primeira: pular o --unshare-user-try ou --unshare-net porque o app reclama, e ai voce tem sandbox de papel. Resolva isso isolando primeiro com --share-net e cortando depois, monitorando com strace -f -e network. Segunda: confiar que Flatpak sozinho protege contra escape via portal D-Bus mal configurado; revise portais com flatpak permissions. Terceira: deixar o microfone aberto. Rode flatpak override --nodevice=all global e libere caso a caso.

Para verificacao continua, integre os perfis com regras Sigma que detectam tentativas de escape Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao e revise trimestralmente, porque manifestos mudam a cada update. Uma sandbox que estava apertada seis meses atras pode ficar escancarada depois de tres updates de apps sem ninguem perceber.

Checklist de partida em cinco passos

Passo um: rode flatpak override --user --nofilesystem=home global e depois devolva so as pastas necessarias por app. Passo dois: troque o leitor de PDF padrao por um wrapper Bubblewrap com bind exclusivo em ~/Downloads e rodando sem --share-net. Passo tres: suba navegador, cliente de e-mail e office pelo Firejail com AppArmor habilitado. Passo quatro: bloqueie microfone e camera global com --nodevice=all e libere so caso a caso. Passo cinco: versione cada wrapper e override em um repo git privado para que a config seja revisavel e reproduzivel.

Trate essa lista como documento vivo. Cada app recem-instalado passa pelo mesmo filtro antes de processar input hostil pela primeira vez: revisar o manifesto, revogar $HOME, rede so sob demanda, dispositivos bloqueados. Em duas semanas o procedimento vira reflexo, o esforco por app novo cai para menos de cinco minutos, e a superficie de ataque fica pequena de forma permanente em vez de voltar a crescer no silencio.

FAQ: Bubblewrap, Firejail ou Flatpak, qual usar?

Use os tres para tarefas diferentes. Flatpak para apps GUI instaladas cujas permissoes voce apara com o Flatseal. Firejail para perfis rapidos e mantidos de programas conhecidos como Firefox e LibreOffice. Bubblewrap para wrappers sob medida com allow-list estrita, como seu leitor de PDF com bind apenas em ~/Downloads. Nao e um ou outro; e uma caixa de ferramentas.

FAQ: sandbox substitui uma VM ou o antivirus?

Nao, complementa os dois. O antivirus tenta detectar ameacas conhecidas; o sandbox limita o dano das desconhecidas. Uma VM traca uma fronteira de kernel para codigo realmente nao confiavel; um sandbox restringe apps confiaveis que processam input hostil. A resposta certa e defesa em profundidade: sandbox para o dia a dia, VM para a analise, patches em dia como base.

Takeaway pratico: comece hoje

Takeaway pratico: comece hoje fazendo flatpak override --user --nofilesystem=home em cada app Flatpak instalado, troque seu leitor de PDF padrao por um wrapper Bubblewrap com bind apenas em ~/Downloads, e versione esses scripts em um repo privado. Em uma tarde voce sobe a barra de exploracao do seu desktop em mais que um ano de patches reativos. Sandbox bem configurado nao impede toda intrusao, mas garante que a primeira CVE de browser do mes nao vire incidente de chaves SSH vazadas. O ROI dessa configuracao se mede em incidentes que nao aconteceram.