Como executar chroot com namespaces do Linux?

A inserção de um namespace de montagem antes de configurar um chroot, permite evitar sobrecarregar o namespace do host com montagens adicionais, por exemplo, para /proc. Você pode usar chrootdentro de um namespace de montagem como um hack agradável e simples.

Eu acho que há vantagens em entender pivot_root, mas tem um pouco de curva de aprendizado. A documentação não explica tudo... embora haja um exemplo de uso em man 8 pivot_root(para o comando shell). man 2 pivot_root(para a chamada do sistema) poderia ser mais claro se fizesse o mesmo e incluísse um exemplo de programa C.

Como usar pivot_root

Imediatamente após inserir o namespace mount, você também precisa mount --make-rslave /ou equivalente. Caso contrário, todas as alterações de montagem serão propagadas para as montagens no namespace original, incluindo o arquivo pivot_root. Você não quer isso :).

Se você usou o unshare --mountcomando, observe que ele está documentado para ser aplicado mount --make-rprivatepor padrão. AFAICS este é um padrão ruim e você não quer isso no código de produção. Por exemplo, neste ponto, ele pararia ejectde funcionar em um DVD ou USB montado no namespace do host. O DVD ou USB permaneceria montado dentro da árvore de montagem privada e o kernel não permitiria que você ejetasse o DVD.

Depois de fazer isso, você pode montar, por exemplo, o /procdiretório que você usará. Da mesma forma que você faria para chroot.

Ao contrário de quando você usa chroot, pivot_rootrequer que seu novo sistema de arquivos raiz seja um ponto de montagem. Se ainda não for um, você pode satisfazer isso simplesmente aplicando uma montagem de ligação: mount --rbind new_root new_root.

Use pivot_root- e depois umounto antigo sistema de arquivos raiz, com a opção -l/ MNT_DETACH. ( Você não precisa umount -R, o que pode levar mais tempo. ).

Tecnicamente, o uso pivot_rootgeralmente precisa envolver chrooto uso também; não é "ou-ou".

De acordo man 2 pivot_rootcom , é definido apenas como trocar a raiz do namespace de montagem. Não está definido para alterar para qual diretório físico a raiz do processo está apontando. Ou o diretório de trabalho atual ( /proc/self/cwd). Acontece que ele faz isso, mas este é um hack para lidar com threads do kernel. A página de manual diz que isso pode mudar no futuro.

Normalmente você quer esta sequência:

chdir(new_root);            // cd new_root
pivot_root(".", put_old);   // pivot_root . put_old
chroot(".");                // chroot .

A posição do chrootnesta sequência é mais um detalhe sutil . Embora o objetivo pivot_rootseja reorganizar o namespace de montagem, o código do kernel parece encontrar o sistema de arquivos raiz a ser movido observando a raiz por processo, que é o que chrootdefine.

Por que usar pivot_root

Em princípio, faz sentido usar pivot_rootpara segurança e isolamento. Gosto de pensar na teoria da segurança baseada em capacidade . Você passa uma lista dos recursos específicos necessários e o processo não pode acessar outros recursos. Neste caso, estamos falando sobre os sistemas de arquivos passados ​​para um namespace de montagem. Essa ideia se aplica geralmente ao recurso "namespaces" do Linux, embora eu provavelmente não esteja expressando isso muito bem.

chrootapenas define a raiz do processo, mas o processo ainda se refere ao namespace de montagem completa. Se um processo retiver o privilégio de executar chroot, ele poderá percorrer de volta o namespace do sistema de arquivos. Conforme detalhado em man 2 chroot, "o superusuário pode escapar de uma 'jaula chroot' por...".

Outra maneira instigante de desfazer chrooté nsenter --mount=/proc/self/ns/mnt. Este é talvez um argumento mais forte para o princípio. nsenter/ setns()necessariamente recarrega a raiz do processo, a partir da raiz do namespace mount ... embora o fato de que isso funcione quando os dois se referem a diretórios físicos diferentes, possa ser considerado um bug do kernel. (Nota técnica: pode haver vários sistemas de arquivos montados um em cima do outro na raiz; setns()usa o topo, o mais recentemente montado).

Isso ilustra uma vantagem de combinar um namespace de montagem com um "namespace PID". Estar dentro de um namespace PID impediria você de inserir o namespace de montagem de um processo não confinado. Também evita que você entre na raiz de um processo não confinado ( /proc/$PID/root). E, claro, um namespace PID também impede que você mate qualquer processo que esteja fora dele :-).