Ubuntu com Criptografia Total + Snapper

Apesar de termos o TimeShift para manipular snapshots no BTRFS, este não funcionará caso você queira trabalhar com criptografia total de disco. Neste caso, podemos então utilizar outra ferramenta para isso, o Snapper. O grande problema, é que o Ubuntu e seus derivados (como o Linux Mint), não está preparado para ele. Neste artigo eu ensinarei como configurar o Ubuntu para poder utilizar esta ferramenta e darei dicas de como você pode instalar o seu sistema com criptografia total.

[ Hits: 927 ]

Por: Daniel R. em 11/02/2020


O problema / O bug



Explicando melhor o problema

A função de snapshots do BTRFS é algo muito útil em qualquer situação, ela permite voltar a um ponto anterior do disco em segundos. Nós temos a ferramenta chamada TimeShift, e ela funciona bem se o seu sistema foi instalado sem nenhuma configuração especial.

O problema aparece quando, por exemplo, usamos criptografia total no disco, neste caso o TimeShift simplesmente não reconhece o sistema instalado sob BTRFS, pois ele está por debaixo de uma camada de criptografia, acredito que o mesmo aconteça caso você utilize o sistema instalado dentro de um volume lógico.

Hoje em dia, eu considero indispensável ter um computador totalmente criptografado, pois existem várias ocasiões onde o seu computador ou HDD, seja tirado de você contra a sua vontade, deixando todos os seus dados expostos, incluindo redes sociais abertas, senhas, documentos, etc. Se isso acontecer, seus dados na mão de outra pessoa vai ser uma preocupação a menos na sua vida, pois a pessoa de posse do seu HDD sem a senha mestre, não terá nada a fazer, além de formatar reinstalar o sistema nele. Nem mesmo o governo e agências de segurança conseguirão acessar seus dados (apesar deles falarem o contrário), se você tiver usando uma senha muito boa, é claro.

A instalação do Ubuntu até oferece instalação com criptografia total, mas usa o Ext4 como sistema de arquivos, neste caso, perdemos o recurso do BTRFS. Se você quer instalar o Ubuntu com criptografia total, usando o BTRFS, eu fiz um script que te ajudará no processo, ele está nesta página do GitHub:
Sendo assim, vamos usar outra ferramenta para criar e restaurar snapshots, o Snapper. Mas infelizmente, o Ubuntu (e seus derivados), não soube utilizar uma boa configuração para utilizar o BTRFS em meu ponto de vista. E isso implica no funcionamento do Snapper. Então, não é uma falha do Snapper, e sim o Ubuntu que monta de forma errada o sistema de arquivos BTRFS, impedindo o Snapper de funcionar como deveria.

O Bug do Ubuntu

O bug do Ubuntu está na forma como ele monta o sistema BTRFS como root. Quando você instala usando o BTRFS, ele cria dois subvolumes, o "@" e o "@home" (isso se você não mandou montar o /home em outra partição), podemos ver isso ao executar o comando como root:

# btrfs sub list /

O subvolume "@" é onde está o root do sistema e a subvolume "@home" é a sua pasta Home. Isso é uma coisa boa, pois podemos trabalhar somente com subvolume "@" que nada influenciará nos seus arquivos de usuário. O problema é que, forçadamente, o Ubuntu sempre vai montar o subvolume "@" como root e vai ignorar o subvolume definido como padrão no sistema de arquivos BTRFS, deixando o sistema engessado.

Ou seja, não adianta criarmos um snapshot do "@", que na verdade é uma cópia linkada do "@", mas com os dados congelados na presente criação do mesmo, e definir este snapshot como subvolume padrão, que ele sempre irá montar o "@" como root. Tanto que ele ignora o subvolume padrão, que se você quiser ver qual subvolume padrão está definido, usando o comando como root:

# btrfs sub get-default /

...ele irá te retornar "ID 5 (FS_TREE)", o subvolume de ID 5 é o próprio root do sistema de arquivo, como ele mesmo cita "FS_TREE", ou seja, totalmente errado considerando o esquema de usar subvolumes. O subvolume padrão correto seria o "@", pois ele é montado como o root do sistema, e será a partir dele que os snapshots serão criados.

Este bug, inclusive, já foi confirmado desde 2018:
Mas até a criação deste artigo, ele não foi corrigido. Ou seja, fique esperto, pois pode ser que futuramente ele seja corrigido e este artigo fique obsoleto. Uma maneira fácil de ver se este bug foi corrigido depois de anos, é verificar qual subvolume está marcado como padrão, se não for o "@", ainda continua na mesma.

Sendo assim, o próximo passo é corrigir este erro de montagem, e fazer primeiramente que o Ubuntu passe a montar o root a partir do subvolume definido como padrão, não sempre o "@".

    Próxima página

Páginas do artigo
   1. O problema / O bug
   2. Corrigindo o problema / Snapper
Outros artigos deste autor

Tor + Privoxy + Squid3

Leitura recomendada

GIT: Controle de versões distribuído para projetos de software

Acessando disquetes no Linux

Instalando e gerenciando programas no Linux

Acessando partições NTFS no Linux

Linux - Quota de disco

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts