Eu sempre costumava manter minha instalação bind9 em uma jaula chroot. Agora atualizei meu vServer e preciso instalar o bind9 novamente. Devido à solução de virtualização que meu provedor de hospedagem usa, não posso criar dispositivos ( /jail/dev/random e /jail/dev/null ), e meu provedor de hospedagem cobra 20 € por isso.
Para citação Adrian Bunk,
Até onde eu entendi esta discussão, executar software como root em um chroot é inútil, já que o usuário root sempre pode escapar da prisão. Mas se eu o executo como um usuário sem privilégios, ele ainda deve fornecer segurança adicional, correto?Incompetent people implementing security solutions are a real problem. Chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different.
Para resumir, vale a pena 20 € colocar o bind9 numa prisão chroot?
Eu percebo que isso é um pouco tarde, mas até onde um chroot não fornece nenhuma segurança "real".
isto está errado!
toda a ideia de segurança é que é fornecida em camadas. Uma grande dica, e a força motriz por trás de muitas distribuições, é fornecer apenas o essencial (em termos de pacotes). isso é porque reduz a superfície de ataque.
um chroot, em essência, é um sistema de arquivos virtualizado. nada mais nada menos. no entanto, o equívoco comum é que, se alguém pode "quebrar o vínculo", então eles também podem sair do chroot ...
mas como? primeiro, toda a discussão sobre o porquê "chroot é inútil" é que os daemons em execução como root podem ser comprometidos para permitir o escalonamento de privilégios de root. mas a maioria das distros executam Bind9 como o usuário nomeado ou vinculado.
portanto, se o atacante WAS comprometesse o Bind, ele teria que vasculhar o sistema de arquivos virtual (o chroot jail) por um aplicativo explorável, biblioteca, executável setuid, etc, usando um buffer overrun , ou jogando com descritores de arquivos, etc, e entregando uma carga útil no sistema base para execução
O Chroot Jails pode funcionar bem, se usado CORRETAMENTE
a idéia por trás de um chroot é fornecer os fundamentos básicos necessários para executar o Bind (neste caso). não é uma boa idéia executar vários aplicativos em um chroot, nem é uma boa idéia colocar os usuários dentro de uma jaula, ao lado de sua instância chrooted de bind. isso só aumentaria a potencial superfície de ataque.
cada aplicativo (especificamente, serviços voltados para frente complexos que recebem informações, que se comunicam diretamente com a Web) deve residir em sua própria cadeia chroot. você poderia colocar todos os seus usuários em uma prisão chroot, mas para minimizar a possível superfície de ataque entre seus usuários (e oferecer mais privacidade potencial), a melhor opção seria ter cada usuário em sua própria prisão chroot, da mesma forma.
finalmente, é preciso proteger o sistema básico em sua totalidade . Desta forma, se você deixar algo explorável na cadeia chroot, eles terão que comprometer o sistema básico antes de serem capazes de causar algum dano real (além do Bind e sua Chroot Jail)
aviso eu disse você; a única pessoa que pode criticar esse processo (tornando a cadeia chroot insegura), é você mesmo . às vezes atualizações ruins ou explorações de dia zero apresentam falhas, mas na maioria das vezes seu erro humano idiomático.
Incompetent people implementing security solutions are a real problem.
minha resposta a isso é que, embora esse seja exatamente o problema (pessoas MUSUSING chroot), ele WAS foi adaptado para ser usado como uma solução de segurança e HAS foi usado em muitas soluções ao longo dos anos (com grande sucesso). nem tudo na vida acaba sendo usado para os fins pretendidos, e este era obviamente um deles.
um exemplo perfeito é o Painel de Controle de Hospedagem na Web. eles geralmente usam o chroot para separar usuários. Além disso, ele tem implementações de trabalho em títulos como Dovecot, Sendmail, Apache / Mod_Security, OpenSSH, e tem sido usado é muitas bibliotecas para fornecer segurança, um exemplo seria pam_chroot.
uma pesquisa simples aumentaria a credibilidade de tal recurso, e é mero absurdo basear a opinião da segurança de seus sistemas em "um equívoco de um equívoco"
O chroot não restringe o acesso do invasor a um subconjunto de arquivos, dificultando a localização de um bug de escalação de privilégio? Em caso afirmativo, ele poderia ser usado como uma ferramenta de segurança. Leitura relevante: link