Por que "chmod -R 777 /" é destrutivo?

255

Esta é uma pergunta canônica sobre permissão de arquivo e por que o 777 é "destrutivo".

Não estou perguntando como corrigir esse problema, pois há muitas referências disso no Server Fault (reinstale o SO). Por que isso faz algo destrutivo?

Se você já executou esse comando, destrói imediatamente seu sistema operacional. Não sei por que a remoção de restrições tem algum impacto nos processos existentes. Por exemplo, se eu não tenho acesso de leitura a alguma coisa e, após um rápido erro de digitação no terminal, de repente agora tenho acesso bem ... por que isso causa a quebra do Linux?

linux permissions chmod samwise
fonte
2
Fiquei sem fôlego quando vi essa pergunta.
Alireza Savand 02/12/12

Respostas:

344

Primeiro de tudo, uma terminologia secundária nitpick: chmodnão remove permissões. Ele MUDA -los.

Agora, a questão principal - o modo 777significa "Qualquer pessoa pode ler, escrever ou executar este arquivo" - Você deu permissão para que alguém faça (efetivamente) o que quiser.

Agora, por que isso é ruim?

  1. Você acabou de deixar todos lerem / modificarem todos os arquivos no seu sistema.
    • Dê um beijo de despedida na segurança da senha (qualquer um pode ler o arquivo shadow e decifrar suas senhas, mas por que se preocupar? Apenas MUDE a senha! É muito mais fácil!).
    • Dê adeus à segurança dos seus binários (alguém pode simplesmente escrever um novo loginprograma que os permita entrar sempre).
    • Dê um beijo de despedida nos seus arquivos: um usuário direciona mal rm -r /e tudo acabou. Foi dito ao sistema operacional para deixá-los fazer o que quisessem!
  2. Você irritou todos os programas que verificam as permissões nos arquivos antes de iniciar.
    sudo,, sendmaile muitos outros simplesmente não iniciam mais. Eles examinarão as principais permissões de arquivo, verificarão que não são o que deveriam ser e retrocederão uma mensagem de erro.
    Da mesma forma, ssheles quebram horrivelmente (os arquivos-chave devem ter permissões específicas, caso contrário, são "inseguros" e, por padrão, o SSH se recusará a usá-los.)
  3. Você eliminou os bits setuid / setgid dos programas que os possuíam.
    O modo 777é realmente . Entre as coisas em que liderar dígitos são o e pedaços. A maioria dos programas que são setuid / setgid tem esse bit definido porque eles devem ser executados com certos privilégios. Eles estão quebrados agora.0777setuidsetgid
  4. Você quebrou /tmpe/var/tmp a outra coisa naquele dígito octal inicial que foi zerado é o sticky bit- Aquilo que protege os arquivos /tmp(e /var/tmp) de serem excluídos por pessoas que não os possuem.
    (Infelizmente) existem muitos scripts mal comportados por aí que "limpam" fazendo um rm -r /tmp/*, e sem o bit fixo definido, /tmp você pode dar adeus a todos os arquivos desse diretório.
    O desaparecimento dos arquivos de rascunho pode realmente incomodar alguns programas mal escritos ...
  5. Você causou estragos em /dev /procsistemas de arquivos similares
    Este é mais um problema nos sistemas Unix mais antigos, onde /devé um sistema de arquivos real, e o material que ele contém são arquivos especiais criados mknod, pois as alterações nas permissões serão preservadas durante as reinicializações, mas em qualquer sistema alterar as permissões do dispositivo pode causar problemas substanciais, desde os óbvios riscos à segurança (todos podem ler todos os TTY) até as causas menos óbvias em potencial de um pânico no kernel.
    Credit to @Tonny for pointing out this possibility
  6. Soquetes e tubulações podem quebrar ou apresentar outros problemas Os soquetes e tubulações podem quebrar completamente ou ser expostos a injeção mal-intencionada como resultado de serem graváveis ​​no mundo.
    Credit to @Tonny for pointing out this possibility
  7. Você fez todos os arquivos em seu sistema executável
    Um monte de pessoas têm .em sua PATHvariável de ambiente (você não deve!) - Isto poderia causar uma surpresa desagradável como agora qualquer um pode soltar um arquivo convenientemente chamado como um comando (por exemplo make, ou ls, e tem a chance de fazer com que você execute o código malicioso.
    Credit to @RichHomolka for pointing out this possibility
  8. Em alguns sistemas chmod, as ACLs (listas de controle de acesso) serão redefinidas.
    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 destrutivo).
    Credit to @JamesYoungman for pointing out this possibility

As partes do sistema que já estão em execução continuarão em execução? Provavelmente, por um tempo, pelo menos.
Mas na próxima vez em que você precisar iniciar um programa, reiniciar um serviço, ou proibir de reiniciar a caixa, você terá um mundo de mágoa, pois os itens 2 e 3 acima criarão suas cabeças feias.

voretaq7
fonte
1
Pelo menos em alguns sistemas /tmpseria corrigido após uma reinicialização. Embora tudo muitas outras coisas pareçam estar quebradas. Pelo menos na VM que acabei de testar, parece que uma reinicialização corrigiu as /tmppermissões. Deve haver algo em um script de inicialização em algum lugar.
Zoredache
@ Zoredache sistemas que utilizam tmpfsnormalmente fixar-se, aqueles que têm / tmp no disco pode (depende de seus scripts de inicialização)
voretaq7
45
+1 por apontar que setuid e setgid seriam eliminados. Este é um aspecto extremamente destrutivo. Tente executar find / -perms -4000 -type fe find / -perms -2000 -type fver vários binários que dependem desses sinalizadores.
27512 Kyle Smith
2
Digitar algo como "less foo.txt" não executaria um arquivo chamado less.txt, independentemente do bit executável definido. Você precisaria ter o diretório less.txt no seu caminho e teria que digitar "less.txt foo.txt" - isso não é algo acidental lá. Mesmo se você estivesse usando a conclusão do shell, ele pararia em menos e você ainda teria que adicionar o .txt. Para chamar um arquivo de texto aleatório com o conjunto de bits executável, você teria que ./nameoffile.txt.
The Real Bill
3
@Deji everyoneé definido como a união de conjunto incluindo o usuário que possui o arquivo, usuários do grupo que possui o arquivo, e os usuários que não atendem a nenhum desses critérios (literalmente os três dígitos de permissões octais: User, Group, e Other). Em outras palavras, qualquer usuário com acesso ao sistema . ("Acesso" nesse contexto pode ser uma conta shell, que é como eu normalmente a abordaria, mas também inclui acesso por meio de um formulário da web / CGI que grava dados no disco: O wwwusuário agora pode gravar em qualquer arquivo no sistema , o que significa que os visitantes aleatórios podem também).
voretaq7
102

Uma coisa importante é que existem muitas ferramentas, como ssh / sudo, que verificam as permissões do sistema de arquivos para os principais arquivos de configuração. Se as permissões estiverem incorretas, essas ferramentas foram projetadas para falhar, pois isso indica um sério problema de segurança. No meu sistema de teste Debian e talvez em outros, a capacidade de fazer 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 foram projetadas para falhar imediatamente quando as permissões estão erradas.

Se você reiniciar um sistema depois de fazer um, chmod 777 -R /ele será inicializado e você poderá iniciar processos que não tenham verificações explícitas de permissão. Assim, o sistema não está realmente morto, apenas um pouco inutilizável por-design .

Zoredache
fonte