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.