containers/bubblewrapFerramenta de sandboxing de baixo nível e sem privilégios usada pelo Flatpak e projetos semelhantes.
Muitas ferramentas de tempo de execução de contêineres, como systemd-nspawn, docker,
etc., concentram-se em fornecer infraestrutura para administradores de sistema e
ferramentas de orquestração (por exemplo, Kubernetes) para executar contêineres.
Essas ferramentas não são adequadas para serem fornecidas a usuários não privilegiados, porque é trivial transformar esse acesso em um shell root totalmente privilegiado no host.
Existe um recurso no kernel Linux chamado namespaces de usuário que permite que usuários não privilegiados usem recursos de contêineres. O Bubblewrap usa esses recursos para construir o sandbox, permitindo que qualquer usuário use a ferramenta.
Historicamente, o bubblewrap também suportava um modo setuid para sistemas nos quais namespaces de usuário não privilegiados não eram suportados. No entanto, isso foi removido.
O código original do bubblewrap existia antes dos namespaces de usuário - ele herda código do xdg-app helper que, por sua vez, deriva remotamente de linux-user-chroot.
Os mantenedores desta ferramenta acreditam que ela não, mesmo quando usada em combinação com software típico instalado nessa distribuição, permite escalonamento de privilégios. No entanto, pode aumentar a capacidade de um usuário logado realizar ataques de negação de serviço.
Em particular, o bubblewrap usa PR_SET_NO_NEW_PRIVS para desativar
binários setuid, que é a maneira tradicional de escapar de coisas
como chroots.
bubblewrap é uma ferramenta para construir ambientes de sandbox. bubblewrap não é um sandbox completo e pronto a usar, com uma política de segurança específica.
Alguns casos de uso do bubblewrap querem uma fronteira de segurança entre o sandbox e o sistema real; outros casos de uso querem a capacidade de alterar o layout do sistema de arquivos para processos dentro do sandbox, mas não pretendem ser uma fronteira de segurança. Como resultado, o nível de proteção entre os processos confinados e o sistema host é inteiramente determinado pelos argumentos passados ao bubblewrap.
Qualquer programa que construa os argumentos de linha de comando para o bubblewrap (muitas vezes uma estrutura maior como Flatpak, libgnome-desktop, sandwine ou um script ad-hoc) é responsável por definir seu próprio modelo de segurança, e escolher os argumentos de linha de comando apropriados do bubblewrap para implementar esse modelo de segurança.
Alguns aspectos da segurança do sandbox que exigem cuidado especial são descritos na seção Limitações abaixo.
Este programa pode ser compartilhado por todas as ferramentas de contêiner que realizam operações sem root, tais como:
Gostaríamos também de ver isso disponível em clusters Kubernetes/OpenShift. Ter a capacidade de usuários não privilegiados usarem recursos de contêiner tornaria significativamente mais fácil realizar cenários interativos de depuração e afins.
O bubblewrap está disponível nos repositórios de pacotes da maioria das distribuições Linux e pode ser instalado a partir deles.
Se você precisar compilar o bubblewrap a partir do código-fonte, faça isso com o meson:
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap funciona criando um namespace de montagem novo, completamente vazio, onde a raiz fica em um tmpfs que é invisível para o host, e será limpo automaticamente quando o último processo sair. Você pode então usar opções de linha de comando para construir o sistema de arquivos raiz, o ambiente do processo e o comando a ser executado no namespace.
Há um script de demonstração maior no
código-fonte, mas aqui está uma versão reduzida que executa
um novo shell reutilizando o /usr do host.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
Este é um exemplo incompleto, mas útil para fins de
ilustração. Mais frequentemente, em vez de criar um contêiner usando a
árvore do sistema de arquivos do host, você deseja usar um chroot. Nesse caso, em vez
de criar o symlink lib64 -> usr/lib64 no tmpfs, você pode
já tê-lo criado no rootfs de destino.
O objetivo do bubblewrap é executar um aplicativo em um sandbox, onde ele tem acesso restrito a partes do sistema operacional ou dados do usuário, como o diretório inicial.
O bubblewrap sempre cria um novo namespace de montagem, e o usuário pode especificar
exatamente quais partes do sistema de arquivos devem estar visíveis no sandbox.
Quaisquer diretórios que você especificar são montados com nodev por padrão e podem ser somente leitura.
Além disso, você pode usar estes recursos do kernel:
Namespaces de usuário (CLONE_NEWUSER): Isso esconde tudo, exceto o uid e gid atuais, do sandbox. Você também pode alterar o valor de uid/gid dentro do sandbox.
Namespaces de IPC (CLONE_NEWIPC): O sandbox terá sua própria cópia de todas as formas diferentes de IPC, como memória compartilhada SysV e semáforos.
Namespaces de PID (CLONE_NEWPID): O sandbox não verá nenhum processo fora do sandbox. Além disso, o bubblewrap executará um pid1 trivial dentro do seu contêiner para lidar com os requisitos de coletar processos filhos no sandbox. Isso evita o que agora é conhecido como o problema do pid 1 no Docker.
Namespaces de rede (CLONE_NEWNET): O sandbox não verá a rede. Em vez disso, terá seu próprio namespace de rede com apenas um dispositivo de loopback.
Namespace UTS (CLONE_NEWUTS): O sandbox terá seu próprio hostname.
Filtros seccomp: Você pode passar filtros seccomp que limitam quais chamadas de sistema podem ser feitas no sandbox. Para mais informações, consulte Seccomp.
Conforme observado na seção Segurança do sandbox acima, o nível de proteção entre os processos confinados e o sistema host é inteiramente determinado pelos argumentos passados ao bubblewrap. Alguns aspectos que exigem cuidado especial são observados aqui.
Se você não estiver filtrando comandos TIOCSTI usando filtros seccomp,
o argumento --new-session é necessário para proteger contra execução de comandos
fora do sandbox
(veja CVE-2017-5226).
Tudo o que é montado no sandbox pode potencialmente ser usado para escalonar privilégios. Por exemplo, se você montar um socket D-Bus no sandbox, ele pode ser usado para executar comandos via systemd. Você pode usar o xdg-dbus-proxy para filtrar a comunicação D-Bus.
Alguns aplicativos implementam seus próprios mecanismos de sandbox, e estes podem ser restringidos pelas limitações impostas pelo sandbox do bubblewrap. Por exemplo, alguns navegadores web que configuram seus processos filhos via seccomp para não terem acesso ao sistema de arquivos. Se você limitar as chamadas de sistema e não permitir a chamada de sistema seccomp, o navegador não poderá aplicar essas restrições. Da mesma forma, se essas regras forem compiladas em um arquivo que não está disponível no sandbox, o navegador não poderá carregar essas regras desse arquivo e não poderá aplicar essas restrições.
Firejail é semelhante ao Flatpak antes de o bubblewrap ser separado, pois combina uma ferramenta setuid com muitos recursos de sandbox específicos de desktop. Por exemplo, o Firejail conhece o Pulseaudio, enquanto o bubblewrap não.
Os autores do bubblewrap acreditam que é muito mais fácil auditar um pequeno programa setuid e manter recursos como a filtragem de Pulseaudio como um processo sem privilégios, como agora ocorre no Flatpak.
Além disso, @cgwalters acha que tentar
colocar caminhos de arquivo na lista de permissões
é uma má ideia, dada a infinidade de maneiras que os usuários têm de manipular caminhos,
e a infinidade de maneiras pelas quais os administradores de sistema podem configurar um
sistema. A abordagem do bubblewrap é reter apenas algumas capacidades Linux
específicas, como CAP_SYS_ADMIN, mas acessar sempre o
sistema de arquivos como o uid que invocou. Isso elimina completamente
ataques TOCTTOU e
afins.
Sandstorm.io exige namespaces de usuário sem privilégios para configurar seu sandbox, embora pudesse ser facilmente adaptado para operar também em modo setuid. @cgwalters acredita que o código deles é razoavelmente bom, mas ainda faria sentido unificar no bubblewrap. No entanto, @kentonv (do Sandstorm) sente que, embora isso faça sentido em princípio, o custo da mudança supera os benefícios práticos por enquanto. Essa decisão pode ser reavaliada no futuro, mas não está sendo ativamente perseguida hoje.
O runC está atualmente trabalhando no
suporte a contêineres sem root,
sem precisar de setuid ou quaisquer outros privilégios durante a instalação do
runC (usando namespaces de usuário sem privilégios em vez de setuid),
criação e gerenciamento de contêineres. No entanto, o modo padrão de
usar o runC é semelhante ao systemd nspawn
na medida em que é uma ferramenta destinada a ser invocada pelo root.
Os autores do bubblewrap acreditam que o runc e o systemd-nspawn não são projetados para se tornarem setuid, e estão distantes de suportar tal modo. No entanto, com contêineres sem root, o runC poderá atender a certos casos de uso que o bubblewrap suporta (com o benefício adicional de ser um runtime OCI padronizado e completo).
O binctr é apenas um wrapper para o runC, então herda todas as suas compensações de design.
O nome bubblewrap foi escolhido para transmitir que esta ferramenta executa como o pai do aplicativo (então o envolve em certo sentido) e cria uma camada protetora (o sandbox) ao redor dele.
(Gato Bubblewrap por dancing_stupidity)