Riscos do Chroot com / dev e / proc

Question

Estou planejando configurar alguns jail chroot para alguns usuários executarem / testarem aplicativos Java (vamos supor que cada aplicativo não seja confiável). Existe algum risco envolvido com a montagem / dev e / proc em cada cadeia? Se houver, que medidas podem ser tomadas para se livrar desse risco?

    

Answer 1

Expor /proc e /dev expõe mais algumas informações e concede mais direitos aos usuários dentro da cadeia.

Tenha em atenção que os uids e os gids podem ser diferentes dentro e fora da cadeia. Por exemplo, dentro da prisão, o usuário "x" pode ser membro do grupo 123, que na cadeia é para "usuários", enquanto no sistema é para "disco". Por bind-montagem /dev , você iria conceder-lhes acesso a dispositivos de disco-primas que lhes permitiria acesso root virtualmente e sair da cadeia.

Eu não ligaria / mount / dev. Apenas crie alguns dispositivos que o aplicativo java possa precisar ( null , tty , zero ...) com a propriedade e os direitos apropriados.

Você já considerou contêineres linux em vez de jars chroot, o que os isolaria mais (os lxcs são apenas um passo a mais para as prisões chroot).

    

Answer 2

Esse é um assunto muito grande, e muito tem sido escrito sobre isso na web, então eu o encorajo a ler um pouco.

O resumo básico é que o chroot nunca foi projetado como um recurso de segurança. Existem muitas maneiras pelas quais um usuário root pode 'escapar' de uma cadeia chroot e algumas maneiras pelas quais um usuário normal pode escapar. Por exemplo, o chroot não possui um espaço de processo separado, portanto um processo dentro do chroot pode 'anexar' a qualquer processo externo usando os mecanismos normais de depuração. Algumas distros modernas têm proteção habilitada que frustraria esse ataque em particular, mas não todas. Em qualquer caso, um usuário root está imune a quase todos esses dispositivos de proteção, e não há nada que o impeça de montar qualquer sistema de arquivos escolhido.

O LXC é melhor, e também é embutido em muitas distros modernas (eu acredito), mas sofre de alguns dos mesmos problemas (em particular, o sistema de arquivos / sys está aberto a abusos).

O OpenVZ é supostamente mais seguro, mas é muito mais difícil de configurar, e eu mesmo não tentei.