Exemplos de por que um diretório /root legível mundialmente é ruim?

Exemplos de por que um diretório /root legível mundialmente é ruim?

Para adicionar peso a uma discussão que estou tendo, estou tentando encontrar exemplos concretos de por que ter o diretório /root legível mundialmente é ruim do ponto de vista da segurança.

Encontrei muitos casos online de pessoas repetindo o mantra de que realmente não é bom dar /root, digamos, 755 permissões, mas sem mais evidências.

Alguém poderia fornecer um cenário em que a segurança de um sistema possa ser comprometida, se for esse o caso? Quanto menos planejado, melhor - então, por exemplo, como um sistema Centos recém-instalado pode sofrer se /root tiver 755 permissões?

EDIT - Obrigado pelas respostas, mas até agora nenhum exemplo concreto. Em outras palavras, como você poderia usar o fato de /root estar visível para comprometer o sistema? Existem exemplos de programas sendo instalados e assumindo que /root não está acessível a todos?

EDIT 2 - Acho que o consenso até agora é que não é um grande risco de segurança, a não ser alguém não verificar as permissões e usar o diretório como se fosse privado para fazer root.

Responder1

Isso não é fundamentalmente diferente da recomendação de impedir que outros usuários leiam o diretório inicial de qualquer outro usuário.

Se o padrão for legível mundialmente, haverá uma janela de oportunidade quando você salvar um novo arquivo que pretende manter privado. Sempre há uma chance de alguém copiá-lo antes de você chmod go-r.

Responder2

Fundamentalmente, acho que se trata de uma escolha feita pelos principais desenvolvedores e nada mais do que isso. Por que? Porque, por padrão, não deve haver quase nada de valor para alguém no /root. Ninguém deve fazer login como usuário root para assuntos gerais.

Por exemplo, no FreeBSD todos podem ler arquivos /root. Alguns arquivos contidos nele /rootnão podem ser lidos por motivos de segurança, mas você ainda pode "ver" os arquivos que estão lá ls(simplesmente não é possível lê-los). Por exemplo, .historyestá definido, -rw-------mas .loginé -rw-r--r--.

O FreeBSD tem uma abordagem de segurança ligeiramente diferente do Linux. Historicamente, o FreeBSD tem sido para servidores e embora possa ser executado como um Desktop, é realmente melhor (por padrão) como um servidor.

Pessoalmente, não vejo nada de errado com esta configuração ( /rootpode ser lido).

O /rootFreeBSD não contém quase nada, exceto configurações. O correio deve ser encaminhado para um usuário real. Ninguém deve fazer login como usuário root. A conta só deve ser usada para instalação e configuração de software, bem como para tarefas de manutenção. Além de alguns arquivos sensíveis à segurança (como .history), não há nada para esconder, /rootna minha opinião, no FreeBSD.

Para ler mais sobre isso, tente oSeção do manual do FreeBSD sobre segurança. Não vi nada na escolha deles para tornar /rootlegível em uma verificação rápida, mas há muitas informações lá.

Responder3

Talvez um administrador descuidado procure por senhas facilmente decifradas e deixe a saída por aí (esta pode não ser a invocação correta, mas você entendeu):

# john-the-ripper /etc/shadow > ~/cracked-passwords.txt

Responder4

Se ~rootfosse gravável, qualquer usuário poderia adicionar sua chave SSH ~root/.ssh/authorized_keyse ter acesso root simplesmente via ssh root@some-host.

Se ~rootfor "meramente" legível, você ainda terá o arquivo rootdo usuário .bash_historyacessível, que pode conter senhas ou outras credenciais inseridas na linha de comando. Ou inserido ou colado acidentalmente em um prompt de comando.

Claro, você não deve passar dados seguros na linha de comando, mas esse aviso geralmente é tratado como de baixo risco porque é arriscado capturá-lo durante o voo e outros usuários não deveriam ser capazes de ler suas variáveis ​​de ambiente de qualquer maneira . Se você tiver acesso ao arquivo rootde .bash_history, você terá acesso a quaisquer dados confidenciais rootque possam ter sido inseridos dessa forma, acidentalmente ou não.

Claro, existem mitigações para esses problemas, como não permitir rooto login no SSH, mesmo com autenticação de chave. Ou desabilitando o histórico do shell. Ou sendo estudioso em limpá-lo. Mas estes sãomitigações; eles são camadas da cebola da segurança.

Ser ~root0700 é outra camada dessa cebola de segurança. Se não quiser chorar, não descasque a cebola mais do que o necessário.

informação relacionada