Por que chroot é considerado inseguro?

Estou brincando com a caixa do CentOS há alguns anos. Então, eu sou bastante confortável com o terminal. No entanto, li muitas postagens no blog alegando que o chroot é inseguro e a quantidade dessas postagens assusta. É mesmo assim? Por quê?

Eu uso o chroot para bloquear os usuários somente de SFTP em um contexto específico, sem nenhum shell ou comando. Então, realmente, qual é o problema de segurança com isso?

A pergunta é exilada do StackOverflow .

— Aleksandr Makov
fonte

Primeiro: a questão não foi fechada / migrada no Stack Overflow , mas está claramente no OT. A ação apropriada seria esperar até que seja migrado ou sinalizá-lo e pedir a um mod para fazê-lo, sem postá-lo em outro site. Mas segundo: se você "brinca com o CentOS", também está errado aqui. Este site é para administradores de sistemas profissionais, não para entusiastas - consulte nossas Perguntas frequentes .

— Sven

@SvenW obrigado, lembrarei da sua dica para o futuro. E sobre o 'segundo', desculpe, mas não vejo como minha pergunta viola o FAQ. Depois de ler duas vezes agora, posso dizer que não. Como na frase "brinque com o CentOS", bem, achei bastante óbvio que os usuários que usam apenas chrooting e somente SFTP e serem considerados sobre a segurança é um tópico muito sério do qual os profissionais podem se beneficiar também em suas empresas ou em qualquer outro " ambientes profissionais ".

— Aleksandr Makov

@sven no caso de você não saber, o SF foi removido da lista de migração da SO devido a quantas perguntas ruins elas nos enviam.

— precisa saber é o seguinte

Respostas:

Porque, na maioria dos casos, um processo raiz pode facilmente sair do chroot. Isso ocorre por design, pois o chroot nunca foi concebido como um dispositivo de segurança.

Alan Cox, de certa forma, repreendeu um desenvolvedor que enviou um patch do kernel para "consertar" esse comportamento, alegando que o chroot foi abusado como um dispositivo de segurança, mas nunca pretendia ser um.

— MDMarra
fonte

Perfeito! Muito obrigado. Portanto, esse é o problema dos processos raiz que estão presentes na raiz ou são acessíveis a partir dela. Obrigado.

— Aleksandr Makov

Acabei de verificar que, executando o programa C mostrado em unixwiz.net/techtips/mirror/chroot-break.html como root no Linux 4.18, é possível escapar do chroot.

— pts

Portanto, não distribua privilégios de root. Até sistemas "seguros" regulares têm contas raiz.

— Cees Timmerman

Conheço pelo menos um exemplo de por que é considerado inseguro. Um ambiente chroot/proc não é isolado, é bastante fácil acessar recursos que não pertencem a processos iniciados no chroot.

Usar um ambiente chroot para SFTP é bom e melhora significativamente o nível de segurança. Apenas não abuse como virtualização baseada em contêiner, o que fornece mais níveis de segurança. Nisto, sublinho o que está na resposta da @ MDMarra.

— gertvdijk
fonte

Obrigado. Portanto, agora fica mais claro que o próprio chroot não é pobre em segurança, mas depende da segurança do ambiente em que está configurado.

— Aleksandr Makov

Na verdade, o chroot não é pobre em segurança, porque nunca foi concebido para ser um dispositivo de segurança. Era para ser uma ferramenta de desenvolvimento para executar várias versões dos mesmos binários lado a lado com diferentes dependências. Não substitui a proteção adequada dos serviços - embora possa ser útil em determinadas circunstâncias, desde que você entenda o que é e o que não é.

— precisa saber é o seguinte

MDMarra, então basicamente o chroot não deve ser usado para capturar conexões SSH. Então, na sua opinião, "fazer chroot nas conexões SSH" soa pouco profissional para você e deve ser evitado?

— Aleksandr Makov

Não, não necessariamente, basta perceber que qualquer exploração que possa levar à elevação de privilégios ou a qualquer processo em execução como raiz no chroot seria trivial. Certamente pode ser uma peça do quebra-cabeça, mas não deve ser a coisa toda.

— precisa saber é o seguinte