Exemplos de porque um diretório readable / root é ruim?

6

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

Encontrei muitas instâncias on-line de pessoas repetindo o mantra que realmente não é bom dizer, 755 permanentes, mas sem mais provas.

Alguém poderia fornecer um cenário em que a segurança de um sistema pode ser comprometida se esse for o caso? Quanto menos artificial for melhor - por exemplo, como um sistema Centos instalado recentemente pode sofrer se / root tiver 755 perms?

EDIT - Obrigado pelas respostas, mas até agora não há exemplos concretos. Para colocar de outra forma, como você poderia usar o fato de que / root é visível para comprometer o sistema? Existem exemplos de programas sendo instalados e assumindo que / root não é acessível a todos?

EDIT 2 - Eu acho que o consenso até agora é que não é um grande risco de segurança, além de alguém não verificar perms e usar o diretório como se fosse privado para root.

    
por einonm 25.04.2017 / 20:25

4 respostas

2

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

Se o padrão for legível pelo mundo, haverá uma janela de oportunidade quando você estiver salvando um novo arquivo que deseja manter em sigilo. Há sempre uma chance de que alguém possa copiá-lo antes que você possa chmod go-r it.

    
por 25.04.2017 / 20:45
2

Fundamentalmente, acho que se trata de uma escolha feita pelos desenvolvedores do núcleo e nada mais do que isso. Por quê? Porque, por padrão, não deve haver quase nada de valor para ninguém em /root . Ninguém deve fazer login como usuário root para informações gerais.

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

O FreeBSD tem uma abordagem ligeiramente diferente da segurança para o 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 essa configuração ( /root pode ser lido).

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

Para ler mais sobre isso, tente a seção do manual do FreeBSD sobre segurança . Eu não vi nada em sua escolha para tornar /root legível em uma varredura rápida, mas há muita informação lá.

    
por 26.04.2017 / 12:37
0

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

# john-the-ripper /etc/shadow > ~/cracked-passwords.txt
    
por 27.04.2017 / 16:05
0

Se ~root fosse gravável, qualquer usuário poderia adicionar sua chave SSH a ~root/.ssh/authorized_keys e ter acesso root simplesmente por meio de ssh root@some-host .

Se ~root for "meramente" legível, você ainda tem o arquivo root user .bash_history acessível, que pode conter senhas ou outras credenciais inseridas na linha de comando. Ou acidentalmente inserido ou colado 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 é difícil capturá-lo durante o vôo, e outros usuários não devem conseguir ler o seu variáveis de ambiente de qualquer maneira. Se você tiver acesso ao arquivo root .bash_history , terá acesso a dados confidenciais root pode ter entrado dessa forma, acidentalmente ou não.

Claro, há atenuações para esses problemas, como não permitir que root faça login no SSH, mesmo com a chave auth. Ou desativando o histórico do shell. Ou sendo estudioso sobre a limpeza. Mas estas são mitigações ; eles são camadas na cebola de segurança.

Ter ~root be 0700 é outra camada nessa cebola de segurança. Se você não quiser chorar, não descasque a cebola mais do que precisa.

    
por 28.04.2017 / 21:42