Questão Mudou o modo de / var no debian


Irã chmod 777 recursivamente em /var/ e não pôde mais se conectar via SSH. Eu li que chmod 600 iria consertar isso. Eu consegui me conectar depois de fazer isso, mas essa foi uma má ideia.

Existe de qualquer maneira eu posso encontrar os modos padrão para as pastas em /var/ ou como consertar isso?

Correndo no Debian-Squeeze.


0


origem


O padrão é 755 nos meus Squeezes. - paradroid


Respostas:


Este é um erro muito comum para pessoas que vêm de um sistema operacional que não tem o conceito de permissão. Muitos

sudo chmod -R 777 /

e tais foram emitidas com talvez boas intenções, mas também é mais ou menos o erro de um usuário que poderia me fazer recomendar "apenas reinstalar" para um sistema * nix.

Se você acabou de chmod -R 755, então você vai, entre outras coisas, ler e execução permissão para todos os arquivos para qualquer pessoa. Se alguém apenas remover a execução de cada arquivo (os diretórios precisarem ser navegáveis), um removerá o bit de execução de alguns arquivos que foram suposto para ser executável e assim por diante.

Neste caso, talvez não seja tão grave quanto -R /mas em p. /var/log existem muitos arquivos que são não deveria ter permissões de leitura para qualquer um. Um pequeno trecho:

-rw-r--r-- alternatives.log
drwxr-x--- apache2
drwxr-xr-x apt
-rw-r--r-- aptitude
-rw-r----- auth.log
-rw-r----- boot
-rw-rw---- btmp
drwxr-xr-x ConsoleKit
drwxr-xr-x cups
-rw-r----- daemon.log
drwxr-xr-x dbconfig-common
-rw-r----- debug
-rw-r----- dmesg
-rw-r--r-- dpkg.log
-rw-r--r-- duplicity-backup.0
drwxr-s--- exim4
-rw-r----- fail2ban.log
-rw-r--r-- faillog
-rw-r--r-- fontconfig.log
drwxr-xr-x fsck
drwxr-xr-x hp
drwxr-xr-x installer
-rw-r----- kern.log
-rw-rw-r-- lastlog
-rw-r--r-- lpr.log
-rw-r--r-- mail.err
-rw-r--r-- mail.info
-rw-r--r-- mail.log
-rw-r--r-- mail.warn
-rw-r----- messages
drwxr-x--- mrtg
drwxr-s--- mysql
-rw-r----- mysql.err
-rw-r----- mysql.log
drwxr-sr-x news
-rw-r--r-- popularity-contest
-rw-r--r-- pycentral.log
-rw-r--r-- rssdler.log
drwxr-xr-x samba
-rw-r----- shorewall-init.log
-rw-r----- syslog
drwxr-xr-x unattended-upgrades
-rw-r----- user.log
-rw-rw-r-- wtmp
-rw-r--r-- Xorg.0.log

Isso não é trivial para restaurar. E isso foi apenas um diretório.

Ao todo, mesmo que você tenha feito o SSH funcionar novamente, você teve algumas perdas de informações de permissão não reparáveis ​​de maneira trivial. Se estiver relacionado a um servidor estritamente pessoal, as conseqüências provavelmente não são tão graves, mas as permissões são definidas da forma mais restritiva possível por um motivo. Em p.ex. Os arquivos de log que mencionei acima, informações confidenciais podem ser armazenadas, e agora é suficiente para uma exploração com direitos de usuário regulares para descobrir isso e obter ainda mais informações para ataques de permissão de root.


Eu vi pela última vez alguém dar o "Do chmod -R 777!!! "dica ontem em um fórum local. Não confie na internet! :-)


3



Bom post, obrigado. Pergunta: por que chmod 777 pausa qualquer coisa se estamos apenas dando permissões para todos? Algumas coisas não funcionam se outras coisas tiverem permissões? - dukevin
@ KevinVuke: É em primeiro lugar um problema de permissão. Como você percebeu, o servidor SSH nem sequer será iniciado se as permissões forem muito frouxas. eu encontrei unix.stackexchange.com/questions/12998/… sobre o tema; leia as duas respostas mais bem classificadas (e ignore com força a resposta aceita, que é legalmente a -6). Eu acredito que eles expressam muito bem a seriedade da situação. - Daniel Andersson
Além do comentário acima: notei que a resposta aceita para a pergunta vinculada que estava em −6 foi excluída agora. - Daniel Andersson