Apagar com segurança arquivos no sistema de arquivos btrfs

20

Às vezes, é necessário excluir um arquivo em um sistema de arquivos e certificar-se de que o arquivo tenha realmente desaparecido. Um arquivo que contém senhas confidenciais, por exemplo, deve ser limpo do disco.

Emitir um rm simples em um sistema de arquivos típico exclui o inode ("ponteiro") do arquivo, mas não exclui o conteúdo do arquivo no disco físico - eles ficam lá até serem sobrescritos quando o sistema de arquivos precisa do espaço livre.

Em muitos sistemas de arquivos, o programa de fragmentação permite essa exclusão segura. No entanto, em um sistema de arquivos CoW como o btrfs, essa abordagem é inútil . O problema é exacerbado pelo fato de que o arquivo pode estar presente em instantâneos de volume.

Existe uma maneira de excluir com segurança um arquivo em um sistema de arquivos btrfs? É suficiente excluir todos os ponteiros (em todos os volumes) e preencher o espaço livre com zeros ?

    
por goncalopp 24.01.2013 / 01:44

3 respostas

8

A exclusão segura é uma proposta difícil em qualquer sistema de arquivos. A menos que o sistema de arquivos seja muito peculiar e garanta que não existam outras cópias do arquivo, é necessário limpar todo o espaço livre no dispositivo. Embora seja mais provável que você encontre muitos bits do arquivo em sistemas de arquivos copy-on-write, sistemas de arquivos ainda mais “estáticos” não têm essa garantia na prática, porque muitos arquivos são editados, então há pouco de versões anteriores do arquivo. arquivo por aí.

Note que apagar com zeros é tão bom quanto apagar com bytes aleatórios, e você não precisa de múltiplas passagens. Apagar com zeros deixou dados residuais que podem ser parcialmente recuperados em condições de laboratório com as tecnologias de disco rígido dos anos 80; isso não é mais aplicável hoje. Veja Por que escrever zeros (ou dados aleatórios) em um disco rígido várias vezes é melhor do que apenas fazer isso uma vez?

Você pode se livrar dos dados confidenciais do texto não criptografado criptografando tudo no disco. Configure um volume ecryptfs sobre esse sistema de arquivos e mova todos os seus arquivos (confidenciais) para ele. Em seguida, sobrescreva todo o espaço não utilizado do sistema de arquivos. Você pode apagar a maior parte preenchendo o sistema de arquivos com cat /dev/zero >zero . Pode ainda haver algumas informações deixadas em blocos incompletos (blocos que contêm o último fragmento de um arquivo, seguido por algum lixo - que poderia ser sobras de um arquivo confidencial). Para garantir que não haja blocos incompletos, mova tudo no sistema de arquivos para o ecryptfs (os arquivos do ecryptfs usam blocos inteiros, pelo menos em configurações típicas onde os blocos são 4kB). Certifique-se de aplicar isso a todos os volumes e apagar todos os instantâneos contendo dados confidenciais de texto simples.

Ainda pode haver algumas informações no diário. Eu não sei como esfregar isso.

No SSD, devido à realocação de blocos, podem existir dados que não podem ser lidos por software normal, mas que podem ser recuperados hackeando o firmware ou com acesso físico. Lá seu único recurso é uma limpeza completa do SSD.

    
por 25.01.2013 / 00:02
4

Hmmm, o btrfs parece derrotar todos os métodos comuns de destruição ...

  • Existe uma opção de montagem chamada nodatacow , mas isso não parece afetar os arquivos já existentes.
  • Como você já possui arquivos sensatos em seu disco, esta FAQ do btrfs entrada não irá ajudá-lo.
  • Depois, há debugfs . É apenas para sistemas de arquivos ext, mas existe um patch para que isso funcione. Você pode usá-lo para descobrir os endereços de bloco afetados e, em seguida, sobrescrevê-los diretamente em / dev / sdXY. Mas isso é muito perigoso e pode não funcionar (especialmente se houver mais snapshots do arquivo)
  • Escreva um patch do btrfs que permita modificar (ou destruir) instantâneos específicos ou um arquivo inteiro
  • A tentativa mais limpa (para dados realmente muito sensíveis) seria:

    • compre outro disco (a menos que você tenha espaço livre suficiente para uma cópia da partição afetada na primeira)
    • configure a criptografia de disco completo e seus sistemas de arquivos
    • copie tudo do disco a para b
    • inicialize no sistema b e destrua o disco inteiro ...

    Esta pode não ser a abordagem mais barata, mas considerando os baixos custos de armazenamento atuais e o problema que você teria com as outras opções, ela poderia ser a mais barata (em termos de horas de trabalho).

por 24.01.2013 / 17:48
-4

Existe shred(1) para Unix / Linux (deve estar nos pacotes da sua distribuição). Eu sou o que a EFF recomenda .

    
por 24.01.2013 / 14:49