Firejail: como isolar aplicações Linux em sandbox (guia 2026)

O Firejail é uma das formas mais simples de adicionar uma fronteira de segurança em torno de uma aplicação Linux comum. Você prefixa um comando com firejail e o programa roda num ambiente restrito que limita o que ele pode ver e tocar no seu sistema. Se esse programa for comprometido mais tarde — um PDF malicioso, uma aba de navegador comprometida, um arquivo de fonte hostil — o dano fica contido dentro da sandbox em vez de alcançar o resto da máquina.

Não é uma solução milagrosa e traz compromissos reais que vale a pena entender antes de confiar nele. Este guia explica o que o Firejail realmente faz, como usá-lo no dia a dia, onde estão seus limites e como ele se compara ao Flatpak e ao Bubblewrap.

Isto complementa a nossa explicação mais ampla sobre isolamento de aplicações no Linux (sandboxing) e a abordagem em camadas do nosso guia de endurecimento do Linux.

O que o Firejail realmente faz

O Firejail é um programa SUID escrito em C. Quando você inicia uma aplicação através dele, ele constrói um ambiente restrito para aquele único processo usando recursos do kernel que já existem no Linux:

• Namespaces do Linux — dão ao programa sua própria visão isolada do sistema de arquivos, da rede, da árvore de processos e de outros recursos, de modo que ele não consiga ver nem interferir nos processos fora da sandbox.
• seccomp-bpf — um filtro de chamadas de sistema que impede o programa de invocar as chamadas do kernel que não tem motivo legítimo para usar, reduzindo a superfície de ataque do kernel.
• Remoção de capabilities — retira as capabilities do Linux (como carregar módulos do kernel ou alterar a hora do sistema) de que uma aplicação de desktop nunca precisa.
• Confinamento do sistema de arquivos — monta partes do sistema de arquivos como somente leitura, oculta outras por completo e pode dar à aplicação um diretório pessoal privado e vazio.

A ideia central é o menor privilégio: um reprodutor de mídia ou um navegador não deveriam ter acesso livre às suas chaves SSH, aos seus documentos fiscais ou a todo o seu diretório pessoal. O Firejail remove esse acesso por padrão para os programas que você executa através dele.

Instalar o Firejail

O Firejail é empacotado pela maioria das distribuições principais.

# Debian / Ubuntu
sudo apt install firejail firejail-profiles

# Fedora
sudo dnf install firejail

# Arch Linux
sudo pacman -S firejail

O pacote firejail-profiles no Debian/Ubuntu fornece a vasta coleção de perfis de segurança pré-escritos — um por aplicação comum — e é aí que reside a maior parte do valor do Firejail. No Fedora e no Arch, os perfis vêm incluídos no pacote principal.

Para confirmar a instalação e ver a versão:

firejail --version

Uso básico

A forma mais simples de executar uma aplicação em sandbox é prefixá-la:

firejail firefox

Se o Firejail incluir um perfil para esse programa (ele traz centenas — Firefox, Chromium, VLC, LibreOffice, Thunderbird, Evince e outros), ele é carregado automaticamente. Você verá uma linha no terminal confirmando o perfil aplicado, por exemplo Reading profile /etc/firejail/firefox.profile.

Para executar um programa sem perfil, apenas com as restrições genéricas padrão:

firejail --noprofile umprograma

Para dar a uma aplicação um diretório pessoal privado, vazio e novo a cada execução — de modo que não deixe nada e não veja nenhum dos seus arquivos reais:

firejail --private firefox

Para bloquear todo o acesso de rede de um programa que não tem por que ir à internet:

firejail --net=none libreoffice --writer

Você pode inspecionar o que está em execução dentro do Firejail e verificar o confinamento:

# Listar as sandboxes ativas
firejail --list

# Mostrar o perfil de segurança de uma sandbox em execução (substitua PID)
firejail --profile.print=PID

Automatizar com o firecfg

Digitar firejail antes de cada comando é tedioso e fácil de esquecer. A ferramenta firecfg integra o Firejail ao sistema para que as aplicações suportadas sejam isoladas automaticamente sempre que forem iniciadas — pelo terminal ou pelo menu do desktop.

sudo firecfg

Isso cria links simbólicos em /usr/local/bin para cada programa instalado que tenha um perfil do Firejail. Depois disso, iniciar firefox pelo menu de aplicações executa de forma transparente firejail firefox nos bastidores. Para desfazer:

sudo firecfg --clean

Verifique quais programas o firecfg assumiu:

firecfg --list

Personalizar e reforçar os perfis

Os perfis ficam em /etc/firejail/ como arquivos .profile. Não os edite diretamente — as atualizações da distribuição os sobrescreveriam. Em vez disso, coloque suas personalizações em ~/.config/firejail/ com o mesmo nome de arquivo, e o Firejail carregará as suas com preferência.

Por exemplo, para dar ao Firefox nenhum acesso de rede e um diretório pessoal limitado aos downloads, crie ~/.config/firejail/firefox.local:

# ~/.config/firejail/firefox.local
private-bin firefox
whitelist ${HOME}/Downloads

Algumas das diretivas de perfil mais úteis:

• private — executar com um diretório pessoal vazio e descartável.
• whitelist <caminho> — tornar visíveis na sandbox apenas os caminhos listados; todo o resto do seu diretório pessoal fica oculto.
• blacklist <caminho> — ocultar caminhos sensíveis específicos (por ex. ${HOME}/.ssh, ${HOME}/.gnupg).
• seccomp — ativar o filtro de chamadas de sistema (ativado por padrão na maioria dos perfis).
• nodbus — bloquear o acesso ao D-Bus, um vetor comum de fuga da sandbox.

Após alterar um perfil, teste a aplicação com cuidado. Restringir em excesso muitas vezes quebra recursos de forma silenciosa (caixas de diálogo de arquivos que não veem os seus arquivos, extensões que não carregam), e uma aplicação quebrada tenta o usuário a desativar a sandbox por completo.

Os limites que você precisa conhecer

O Firejail melhora a sua postura de segurança, mas carrega ressalvas genuínas. Seja honesto consigo mesmo a respeito delas.

É SUID root. O binário firejail roda com privilégios de root para poder configurar os namespaces e as montagens. Isso significa que uma falha no próprio Firejail é um caminho para escalonamento de privilégios, e o Firejail já teve CVEs desse tipo no seu histórico. Uma ferramenta de segurança complexa que roda como root é, ela própria, superfície de ataque — exatamente a crítica feita ao modelo SUID.

Os perfis são o melhor esforço, não garantias. Um perfil vale o que o seu autor fez dele. Um perfil mal delimitado, ou uma execução com --noprofile, oferece apenas um confinamento fraco. A proteção que você obtém depende muito do perfil aplicado e do seu rigor.

Não substitui um kernel reforçado nem um MAC. O Firejail assenta sobre as suas defesas existentes. Ele complementa — não substitui — AppArmor/SELinux, o endurecimento do kernel e a criptografia do disco. Veja o nosso guia de endurecimento do Linux para as camadas subjacentes.

O suporte varia conforme a distribuição. Por causa da preocupação com o SUID, algumas configurações voltadas à segurança preferem o modelo alternativo abaixo.

Firejail vs Bubblewrap vs Flatpak

Estas são as três abordagens de isolamento que você encontrará com mais frequência no Linux.

Bubblewrap é o bloco de base sem privilégios — apoia-se nos namespaces de usuário em vez de um binário SUID, por isso tem uma superfície de confiança muito menor, mas é uma ferramenta do tipo biblioteca que não inclui perfis de aplicação prontos. Flatpak usa o Bubblewrap por baixo dos panos e adiciona um sistema de permissões baseado em portais, mas só confina as aplicações que você instala via Flatpak. A vantagem do Firejail é a abrangência: ele consegue envolver quase qualquer binário que já esteja no seu sistema, incluindo os dos repositórios normais da sua distribuição, sem reempacotar.

Uma configuração pragmática comum: usar Flatpak (baseado no Bubblewrap) onde existir um bom Flatpak, e recorrer ao Firejail para confinar os pacotes nativos sem sandbox própria. Para a nossa comparação mais ampla das estratégias de isolamento, veja o isolamento de aplicações no Linux, e para escolher uma base reforçada, as distribuições Linux mais seguras.

Perguntas frequentes

P: É seguro usar o Firejail, dado que ele roda como root? R: Para a maioria dos usuários de desktop, ele eleva a barreira contra exploits em nível de aplicação mais do que a baixa. O compromisso honesto é que o binário SUID firejail é, ele próprio, superfície de ataque com privilégios de root e já teve CVEs de escalonamento de privilégios. Se o seu modelo de ameaça inclui um atacante local sofisticado, o modelo sem privilégios do Bubblewrap/Flatpak é a escolha mais prudente. Para confinar um navegador ou um reprodutor de mídia diante de conteúdo hostil, o Firejail é uma ferramenta razoável e eficaz.

P: O Firejail deixa as aplicações mais lentas? R: A sobrecarga é pequena para o uso típico de desktop. Configurar os namespaces e o filtro seccomp adiciona um breve custo no início, e o filtro de chamadas de sistema tem impacto desprezível em tempo de execução para a maioria dos programas. É improvável que você note em navegadores, suítes de escritório ou reprodutores de mídia.

P: Como isolo todas as aplicações automaticamente? R: Execute sudo firecfg. Ele cria links simbólicos para que qualquer programa instalado com um perfil do Firejail seja iniciado através do Firejail automaticamente, pelo terminal ou pelo menu do desktop. Execute sudo firecfg --clean para reverter.

P: O Firejail vai quebrar minhas aplicações? R: Pode acontecer se um perfil for restritivo demais — normalmente caixas de diálogo para abrir arquivos que não veem os seus arquivos, extensões que não carregam ou acesso de rede bloqueado. Se uma aplicação se comportar mal, teste-a com firejail --noprofile <app> para confirmar que o perfil é a causa, e depois afrouxe a diretiva relevante (muitas vezes um caminho whitelist) em ~/.config/firejail/<app>.local em vez de desativar a sandbox.

P: O Firejail é o mesmo que uma máquina virtual? R: Não. Uma VM roda um kernel separado completo e constitui uma fronteira de isolamento muito mais forte. O Firejail compartilha o kernel do seu host e confina um único processo usando recursos do kernel. É mais leve e bem mais conveniente, mas um exploit em nível de kernel ainda pode atravessá-lo. Para uma compartimentação de alta garantia, um sistema baseado em VM como o Qubes OS é a ferramenta apropriada.