Proteção de arquivos no Unix

6

Existe uma maneira de proteger um arquivo de tal forma que mesmo root não possa apagá-lo ou reescrevê-lo depois de criá-lo? Eu tenho um arquivo que é criado por root em /var/log/ e eu quero restringir todos os usuários (incluindo root ) para que eles possam ler esse arquivo específico depois que ele foi criado.

    
por coffeMug 16.12.2013 / 21:00

7 respostas

7

Não, não há como fazer isso, que eu saiba. A resposta sobre chflags refere-se às variantes do BSD. Um comando similar para o Linux é chattr .

O conceito do usuário root é que eles podem fazer qualquer coisa no sistema.

    
por 16.12.2013 / 21:13
3

Você pode estar procurando o sinalizador "system immutable". Os detalhes podem depender precisamente de qual sistema operacional você está executando, mas a ideia básica será a mesma. Você vai querer algo assim no BSD (ou OSX):

# chflags schg /path/to/file

ou o equivalente no Linux:

# chattr +i /path/to/file

Note que root pode sempre remover o sinalizador imutável do sistema para alterar o arquivo , então sua próxima opção é colocar o arquivo em um sistema de arquivos somente leitura. Mesmo assim, com o acesso root, ainda é possível desmontar um sistema de arquivos somente leitura e montá-lo como leitura-gravação.

O próximo passo seria colocá-lo em um disco físico que tenha uma chave de proteção contra gravação. Verifique com seu fornecedor para ver se isso está disponível em seu hardware. Se não for, você pode considerar colocar os arquivos em uma unidade WORM de algum tipo. Um CD-R é uma opção.

Que tal colocar o arquivo em um sistema de arquivos NFS somente leitura armazenado em outro servidor?

Provavelmente, é mais fácil descobrir uma solução melhor para este problema XY .

    
por 16.12.2013 / 21:04
2

De um modo geral, o root pode fazer tudo. Quaisquer que sejam as etapas que você execute para impedir que o root faça alguma coisa (como configurar atributos do arquivo), o root poderá desfazer.

O OpenBSD e o FreeBSD têm uma noção do nível de segurança , também conhecido como securelevel. O securelevel é um valor inteiro. Se o valor for negativo ou 0, somente as regras normais de segurança do Unix serão aplicadas. No securelevel 1 e acima, várias restrições são implementadas, em particular:

  • É impossível reduzir o valor do nível de segurança.
  • É impossível carregar ou descarregar qualquer módulo do kernel. Assim, o código em execução no modo kernel não pode mais ser alterado.
  • O acesso bruto à memória ou a dispositivos de bloco está desativado.
  • A chamada de sistema chflags nega a tentativa de remover o arquivo imutável ou sinalizadores de anexação somente de qualquer arquivo.

Securelevels 2 e 3 adicionam restrições adicionais. O importante é que é impossível reduzir o nível de segurança sem reinicializar, mesmo com acesso root. Assim, os níveis de segurança trazem restrições para o que o root pode fazer, às custas de impossibilitar certas tarefas de manutenção (como reparar ou reconfigurar um array RAID).

É claro que essas restrições só são eficazes contra usuários que não têm acesso à máquina física ou a um console durante a inicialização. Os dados do carregador de inicialização (incluindo o arquivo do kernel) devem ser imutáveis, caso contrário, um usuário root poderia introduzir um backdoor e disparar ou esperar por uma reinicialização.

Pode ser possível configurar algo assim com as estruturas de segurança do Linux (AppArmor, SELinux,…), mas estas são principalmente ferramentas para definir políticas restritivas para processos que não estão sendo executados como root. Se for de todo possível, exigiria muito cuidado na definição da política (mesmo no caso normal, é difícil conceber políticas úteis).

Se você não tem a opção de restringir o poder do root dessa maneira, a maneira de tornar um arquivo somente leitura para o root é armazená-lo em um sistema diferente. As opções incluem:

  • Execute o sistema em uma máquina virtual e armazene o arquivo no host.
  • Armazene o arquivo em outro sistema acessível pela rede.
  • Armazene o arquivo em uma mídia fisicamente somente de leitura.
por 17.12.2013 / 01:14
1

Parece que a única maneira válida é usar o comando chattr da seguinte forma:

chattr +i /var/log/file

Desta forma, mesmo o root não pode modificar o arquivo, a menos que ele remova o atributo i do arquivo.

Portanto, é apenas um passo em direção a uma melhor proteção, eu acho.

    
por 16.12.2013 / 21:13
1

O arquivo será congelado ou você precisa continuar escrevendo? No primeiro caso, você poderia colocar o arquivo em uma mídia de somente leitura: CD-ROM, flash drive com uma chave física de proteção contra gravação, etc. (Isso protege a integridade do arquivo, mas não impede que o root seja desmontado). e / ou mascarando-o com uma farsa).

Se você quiser continuar gravando no arquivo de log, não haverá solução, a menos que você possa encontrar uma mídia física write-once-read-many: Se um arquivo puder ser gravado, ele poderá ser sobrescrito. (Para completar: É possível definir o atributo "somente anexo" de um arquivo com chattr ou chflags , o que protegerá o conteúdo do arquivo de ser sobrescrito. Mas não é possível impedir que a raiz desative esse atributo.)

    
por 16.12.2013 / 23:37
0

chattr pode fazer isso, ou pelo menos algo bem próximo disso. Existem dois atributos que podem ser relevantes, dependendo do comportamento exato que você deseja.

Por exemplo, você pode querer definir o atributo a , usando chattr +a filename :

A file with the 'a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Como isso parece ser um arquivo de log, essa pode ser a opção mais apropriada. Ou você pode usar o atributo i :

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Observe que o superusuário pode limpar esses atributos com o comando chattr -X correspondente.

    
por 16.12.2013 / 21:14
0

Isso não responde exatamente à pergunta, mas uma solução alternativa é ter o log em funcionamento em um servidor / VM diferente, torná-lo somente para anexar usando chattr +a e, em seguida, montá-lo na rede. Isto não é sem inconvenientes, mas na minha opinião é uma das melhores abordagens para resolver este problema.

    
por 25.07.2015 / 22:21