Confira !!
O pesquisador de segurança e engenheiro da Microsoft Mickaël Salaün está propondo suporte chroot sem privilégios para o kernel do Linux.
Com um patch enviado hoje, ele observou: " A chamada do sistema chroot está atualmente limitada para ser usada por processos com o recurso CAP_SYS_CHROOT. Isso protege contra processos maliciosos que tentam enganar binários do tipo SUID. O patch a seguir permite que usuários sem privilégios usem chroot com segurança (2) ... Ser capaz de alterar facilmente os diretórios raiz permite facilitar algum fluxo de trabalho de desenvolvimento e pode ser usado como uma ferramenta para fortalecer caixas de proteção de segurança sem privilégios. Chroot (2) não é um mecanismo de controle de acesso por si só, mas pode ser usado para limitar a visão absoluta do sistema de arquivos e, em seguida, limitar as formas de acessar dados e interfaces do kernel. "
O patch proposto permite que as tarefas no_new_privs chamem o chroot. Salaün argumentou seu caso na mensagem do patch:
Os usuários podem não querer expor a complexidade do namespace a processos potencialmente maliciosos ou limitar seu uso devido a recursos limitados. O recurso chroot é muito mais simples (e limitado) do que o namespace de montagem, mas ainda pode ser útil. Quanto aos contêineres, os usuários do chroot (2) devem cuidar dos descritores de arquivo ou dados acessíveis por outros meios (por exemplo, diretório de trabalho atual, FDs vazados, FDs aprovados, dispositivos, pontos de montagem, etc.). Há muita literatura que discute as limitações do chroot, e os usuários desse recurso devem estar cientes das várias maneiras de contorná-lo. Usar chroot (2) para fins de segurança pode fazer sentido se for combinado com outros recursos (por exemplo, usuário dedicado, seccomp, controles de acesso LSM, etc.).
Alguém poderia argumentar que chroot (2) é inútil sem uma hierarquia de raiz devidamente populada (ou seja, sem / dev e / proc). No entanto, existem vários casos de uso que não requerem o processo de chrooting para criar hierarquias de arquivos com arquivos especiais nem pontos de montagem, por exemplo:
* Um processo de sandboxing em si, uma vez que todas as suas bibliotecas são carregadas, pode não precisar de outros arquivos além de arquivos regulares, ou mesmo nenhum arquivo.
* Algumas hierarquias de raiz pré-populadas podem ser usadas para fazer o chroot, fornecidas, por exemplo, por ambientes de desenvolvimento ou distribuições personalizadas.
* Os processos executados em um chroot podem não requerer acesso a esses arquivos especiais (por exemplo, com tempos de execução mínimos ou pela emulação de alguns arquivos especiais com uma biblioteca LD_PRELOADed ou seccomp).
Permitir que uma tarefa mude seu próprio diretório raiz não é uma ameaça ao sistema se pudermos evitar ataques de deputados confusos, que podem ser realizados por meio da execução de binários do tipo SUID. Isso pode ser evitado se a tarefa de chamada definir PR_SET_NO_NEW_PRIVS em si mesma com prctl (2). Para afetar apenas esta tarefa, as informações do sistema de arquivos não devem ser compartilhadas com outras tarefas, o que pode ser alcançado não passando CLONE_FS para o clone (2). Uma verificação no_new_privs semelhante já é usada pelo seccomp para evitar o mesmo tipo de problemas de segurança. Além disso, por causa de seu uso de segurança e para evitar dar uma nova maneira para os invasores saírem de um chroot (por exemplo, usando / proc // root), um chroot sem privilégios só é permitido se o novo diretório raiz for o mesmo ou abaixo do atual. Isso ainda permite que um processo use um subconjunto de seu sistema de arquivos legítimo para fazer o chroot e, em seguida, reduza ainda mais sua visão do sistema de arquivos.
Esta mudança não pode impactar os sistemas que dependem de outros modelos de permissão além dos recursos POSIX (por exemplo, Tomoyo). Ser capaz de usar chroot (2) em tais sistemas pode exigir a atualização de suas políticas de segurança.
A mudança em si é apenas um patch de 64 linhas, mas considerando que é uma mudança fundamental, veremos em breve o que os desenvolvedores do kernel upstream pensam sobre essa mudança liderada pela Microsoft para permitir suporte chroot sem privilégios no Linux.
Até a próxima !!
Nenhum comentário:
Postar um comentário