Alterou o modo de / var no debian

0

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

Existe alguma maneira que eu possa encontrar os modos padrão para as pastas em /var/ ou como corrigir isso?

Executando no Debian-Squeeze.

    
por dukevin 25.05.2012 / 01:21

1 resposta

3

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 emitidos com 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ê apenas chmod -R 755 , então, entre outras coisas, dará permissão de leitura e execução para todos os arquivos. Se alguém apenas remover a execução de cada arquivo (os diretórios precisam que ele seja navegável), então um removerá o bit de execução de alguns arquivos que foram supostos para serem executáveis, e assim por diante.

Neste caso, talvez não seja tão grave quanto -R / , mas em, e. /var/log há muitos arquivos que não devem ter permissões de leitura para ninguém. 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.

Em resumo: mesmo que você tenha feito o SSH funcionar novamente, você teve algumas perdas de informações de permissão não reparáveis de forma 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 do 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! : -)

    
por 25.05.2012 / 09:01

Tags