Como posso forçar programas com chroot a usar um dispositivo ethernet virtual?

Question

Primeiro, isso é não por motivos de segurança ou para uso em um ambiente de produção. É porque quero mexer com sistemas de gerenciamento de configuração diferentes em estações de trabalho de especificação relativamente baixa, sem usar VMs (sobrecarga de tempo e recursos) ou LXC (requisitos de versão e complexidade desnecessária). Os Chroots são relativamente inseguros, mas também são rápidos e fáceis de configurar.

De qualquer forma: dado um ambiente chroot e uma interface ethernet virtual (eth0: 1 ou algo parecido), como posso ter certeza de que os programas no chroot sempre usam a interface virtual?

Note que eu não preciso de isolamento de rede verdadeiro, onde a interface real não pode ser vista dentro do chroot. Eu só quero que os programas chrooted respondam a um endereço IP diferente do host (ou outros chroots), para que eu possa usar as configurações de servidor / cliente corretamente, por exemplo, Fantoche.

O host está executando o Debian Wheezy x64.

Talvez eu esteja me aproximando disso da maneira errada. O que eu quero é ter vários chroots e poder acessar cada um pelo hostname do sistema host. Isso é possível?

    

Answer 1

O Chroot não ajuda aqui. Isso afeta apenas nomes de arquivos, não de rede e outros recursos.

As versões modernas do Linux oferecem uma maneira de virtualizar alguns aspectos do ambiente, por meio de namespaces . Além da virtualização tradicional de nomes de arquivos através de chroot (para que um processo não enxergue arquivos fora do chroot), é possível virtualizar IDs de processo (para que um processo dentro de um namespace PID não possa sinalizar ou rastrear processos fora do namespace), usuários (para que o usuário 1234 dentro do namespace do usuário seja independente do usuário 1234 fora do namespace), etc. É de interesse para você namespaces de rede , nos quais os processos têm suas próprias interfaces de rede, Endereços IP, roteamento, etc.

Eu recomendo a leitura da excelente série de artigos do LWN por Michael Kerrisk , pelo menos a introdução e o artigo sobre "http://lwn.net/Articles/219794/"> namespaces da rede .

Os namespaces de rede existem desde o kernel 2.6.29 (com uma implementação parcial disponível em versões anteriores), então eles estão disponíveis em todas as distribuições contemporâneas, exceto no RHEL5 / CentOS5. A partir do kernel 3.8, você pode até combinar um namespace de rede com um namespace de usuário e executar a configuração de rede dentro do namespace, sem ter permissões de root fora do namespace; com kernels anteriores, como o 3.2 on wheezy, você precisa de acesso root no sistema host para criar o namespace do usuário. As ferramentas de Userland têm sido mais lentas do que os recursos do kernel, portanto muitos sistemas atuais não possuem todas as ferramentas para fazer uso total dos recursos do kernel. O Debian wheezy vem com unshare , o que é suficiente para criar esse namespace, mas não possui o wrapper do shell nsenter around setns para atuar dentro de um namespace do host (ele entrou instável em julho ).

Veja Comando para executar um processo filho" offline "(sem rede externa) no Linux para um exemplo simples de criação de um namespace de rede. O blog de Scott Lowe tem um tutorial mais detalhado.

    

Answer 2

Resposta: tanto quanto eu posso dizer de um Googling razoavelmente extenso, a falta de namespace de rede no chroot na verdade torna isso impossível. Você não pode atribuir a um ambiente chroot seu próprio IP, seu próprio nome de host ou FQDN, ou qualquer coisa nesse sentido, por qualquer meio.

O Chroot é útil para proteger programas simples ou daemons. Para criar qualquer tipo de sistema de teste isolado, parece ser praticamente inútil.