Por que é ruim ter arquivos de gravação raiz em um diretório não pertencente à raiz?

Isso surgiu em um comentário para outra pergunta e eu adoraria se alguém pudesse me explicar os motivos disso.

Sugeri que o Apache registrasse os erros de um determinado VHost no diretório pessoal de um usuário. Isso foi abatido porque era inseguro. Por quê?

Pedi esclarecimentos em um comentário de resposta, mas tudo o que obtive foi que não é seguro ter a raiz gravada em uma pasta que não pertence à raiz. Mais uma vez, alguém poderia explicar?

Obrigado,

Bart.

linux security permissions

— Bart B
fonte

O que o Apache está executando como root - o princípio do menor privilégio clama contra isso!

— 31411 Jonathan Leffler

O Apache está sendo executado como www, mas está sendo iniciado como root, para que possa ligar-se à porta 80 como é a norma. Aparentemente, ele também registra como root.

— 22630 Bart B

Como um usuário mal intencionado pode tentar apontar o arquivo que rootestá gravando para um local diferente . Isso não é tão simples, mas realmente possível.

Como exemplo, se um usuário encontrar o caminho para fazer um link simbólico do suposto log do Apache para, digamos, / etc / shadow, você terá um sistema inutilizável de repente. O Apache ( root) sobrescreveria as credenciais de seus usuários, causando falhas no sistema.

ln -s /etc/shadow /home/eviluser/access.log

Se o arquivo access.log não for gravável pelo usuário, pode ser difícil seqüestrá-lo, mas evitar a possibilidade é melhor!

Uma possibilidade pode ser usar logrotate para fazer o trabalho , criando o link para um arquivo ainda não existente, mas esse logrotate será substituído assim que os logs aumentarem:

ln -s /etc/shadow /home/eviluser/access.log.1

Nota :

O método de link simbólico é apenas um dos ataques possíveis, dados como prova de conceito.

A segurança deve ser feita com a mente da Lista Branca , sem incluir na lista negra o que sabemos ser um problema.

— AlberT
fonte

Existe uma maneira de definir permissões nele para que eles possam apenas ler o arquivo e não excluir, editar ou fazer qualquer outra coisa (como chown, chmod, etc.)?

— Joshua

você deve fazer esta operação em todos os arquivos de destino possíveis! esse arquivo gravável é o preferido, não o link em si pertencente ao invasor quando ele o criou.

— drAlberT 22/09/09

@ Josué: chown só pode ser executado pela raiz. O chmod pode ser executado por quem possuir o arquivo. IIRC, a renomeação pode ser feita por quem possuir o diretório. Como o AlberT menciona, a criação de um link antes da raiz criar o arquivo pode ser feita por quem puder gravar no diretório.

— atk

@atk: Além disso, quem possui o diretório geralmente pode remover arquivos dele (a menos que o +tbit fixo esteja definido), mesmo se eles não tiverem permissão de gravação para os próprios arquivos (porque unlink () é uma gravação no diretório, não o Arquivo). Mesmo que o root crie o arquivo com antecedência, o proprietário do diretório ainda poderá excluí-lo e substituí-lo por um link simbólico para outra coisa.

— James Sneeringer

Se eviluser puder escrever em / home / eviluser (ou alterar as permissões no diretório - elas são suas, IOW), não importará quais são as permissões no access.log; o usuário mau pode (re) mover o arquivo e colocar seu link simbólico em seu lugar. Outra questão é se o software presta atenção ao que abre.

— 31411 Jonathan Leffler

O princípio geral de não ter processos gravados em um diretório que eles não possuem ou confiam é bom. Mas neste caso em particular, é razoável confiar que o código Apache abre o log com O_NOFOLLOWetc: fazer login no diretório pessoal de um usuário é uma configuração comum.

— poolie
fonte