Por que “chmod -R 777 /” é destrutivo?

Question

This is a Canonical Question about File Permission and Why 777 is "destructive".

Não estou perguntando como consertar este problema, pois há uma tonelada de referências do que já está no Server Fault (reinstalar o SO). Por que isso faz algo destrutivo?

Se você já executou esse comando, praticamente destruiu seu sistema operacional imediatamente. Não estou claro por que a remoção de restrições tem algum impacto nos processos existentes. Por exemplo, se eu não tiver acesso de leitura a algo e depois de um rápido erro de digitação no terminal, de repente eu tenho acesso bem ... por que isso causa a quebra do Linux?

    

Answer 1

Em primeiro lugar, um pequeno detalhe de terminologia: chmod não remove as permissões. É CHANGES .

Agora, a carne do problema - O modo 777 significa "Qualquer pessoa pode ler, escrever ou executar este arquivo" - Você tem permissão dada para qualquer um fazer (efetivamente) eles querem.

Agora, por que isso é ruim?

1. Você acabou de permitir que todos leiam / modifiquem todos os arquivos do seu sistema.
   • Deseje adeus à senha de segurança (qualquer um pode ler o arquivo de sombra e decifrar suas senhas, mas por que se incomodar? Basta MUDAR a senha! É muito mais fácil!).
   • Dê adeus à segurança dos seus binários (alguém pode simplesmente escrever um novo programa login que os permita entrar em todos os momentos).
   • Deseje adeus aos seus arquivos: um usuário desviou rm -r / e está tudo acabado. O sistema operacional foi dito para deixá-los fazer o que quisessem!
2. Você irritou todos os programas que verificam as permissões nos arquivos antes de começar.
   sudo , sendmail e uma série de outras pessoas simplesmente não iniciarão mais. Eles examinarão as permissões do arquivo-chave, verão que não são o que deveriam ser e retornarão uma mensagem de erro.
   Da mesma forma, ssh irá quebrar horrivelmente (os arquivos-chave devem ter permissões específicas, caso contrário, eles são "inseguros" e, por padrão, o SSH se recusará a usá-los).
3. Você eliminou os bits setuid / setgid nos programas que os tinham.
   O modo 777 é, na verdade, 0 777 . Entre as coisas nesse dígito principal estão os setuid e setgid bits.
   A maioria dos programas setuid / setgid tem esse bit definido porque eles devem ser executados com certos privilégios. Eles estão quebrados agora.
4. Você quebrou /tmp e /var/tmp A outra coisa nesse dígito octal inicial que foi zerado é a sticky bit - Aquilo que protege os arquivos em /tmp (e /var/tmp ) de serem excluídos por pessoas que não os possuem.
   Existem (infelizmente) muitos scripts mal-comportados por aí que "limpam" fazendo um rm -r /tmp/* , e sem o bit pegajoso definido em /tmp você pode dar adeus a todos os arquivos do diretório.
   Ter arquivos de raspar desaparecidos pode realmente atrapalhar alguns programas mal escritos ...
5. Você causou estragos em /dev /proc e sistemas de arquivos semelhantes
   Isso é mais um problema em sistemas Unix mais antigos, onde /dev é um sistema de arquivos real, e o material que ele contém são arquivos especiais criados com mknod , pois as permissões serão preservadas nas reinicializações, mas em qualquer sistema que tenha seu dispositivo a mudança de permissões pode causar problemas substanciais, desde os óbvios riscos de segurança (todos podem ler cada TTY) até as causas menos óbvias de um pânico no kernel.
   Credit to @Tonny for pointing out this possibility
6. Soquetes e Pipes podem quebrar ou ter outros problemas Soquetes e cachimbos podem quebrar completamente ou serem expostos a uma injeção mal-intencionada como resultado de serem graváveis em todo o mundo.
   Credit to @Tonny for pointing out this possibility
7. Você criou todos os arquivos no seu sistema executável
   Muitas pessoas têm . em sua variável de ambiente PATH (você não deveria!) - Isso pode causar uma surpresa desagradável, pois agora qualquer um pode soltar um arquivo convenientemente chamado como um comando (digamos make ou ls e ter uma chance de fazer com que você execute seu código malicioso.
   Credit to @RichHomolka for pointing out this possibility
8. Em alguns sistemas, chmod redefinirá as listas de controle de acesso (ACLs)
   Isso significa que você pode ter que recriar todas as suas ACLs além de corrigir permissões em todos os lugares (e é um exemplo real do comando ser destrutivo).% Credit to @JamesYoungman for pointing out this possibility

As partes do sistema que já estão em execução continuam sendo executadas? Provavelmente, por um tempo pelo menos. Mas da próxima vez que você precisar lançar um programa, ou reiniciar um serviço, ou o céu proíbir REINICIALIZAR a caixa que você está com um mundo de mágoa, as posições # 2 e # 3 acima farão suas feias cabeças.

    

Answer 2

Uma coisa importante é que existem muitas ferramentas como o ssh / sudo que verifica as permissões do sistema de arquivos para os arquivos de configuração principais. Se as permissões estiverem erradas, essas ferramentas serão projetadas para falhar, pois isso indicaria um sério problema de segurança. No meu sistema de teste Debian e talvez em outros, a capacidade de login falha, provavelmente porque o binário de login ou algo no PAM tem verificações de permissão.

Portanto, não é realmente que o sistema seja destruído - é que muitas ferramentas são projetadas para falhar imediatamente quando as permissões estão erradas.

Se você reinicializar um sistema depois de executar um chmod 777 -R / , ele será inicializado e você poderá iniciar processos que não tenham verificações de permissão explícitas. Então, o sistema não está realmente morto, apenas um pouco inutilizado pelo .