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: 1.727 ]

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

Montando partições para outros usuários acessar

Usando partições e sistemas de arquivos

Convertendo Sistemas de Arquivos

Automatizando a montagem de partições Windows (FAT e NTFS) no Linux

Montar partições NTFS com Fuse e NTFS-3G no Debian Etch

  
Comentários
[1] Comentário enviado por juamspk em 21/03/2020 - 13:14h

Obrigado pelo artigo, comecei a estudar sobre o BTRFS recentemente pelos snapshots, infelizmente o conteudo sobre não é tão vasto então tô quebrando cabeça pra entender a estrutura geral dele, sobre a criptografia nunca tinha pensado muito sobre mas agora vou seriamente ver sobre isso ja que o perigo de ter meu note roubado é real(perigoso por aqui).
tô querendo usar o BTRFS no meu manjaro (SSD 240GB pro SO e HD 1TB pros arquivos) nessa caso os dois discos precisariam ser criptografados?

[2] Comentário enviado por dantavares em 21/03/2020 - 17:29h


[1] Comentário enviado por juamspk em 21/03/2020 - 13:14h

Obrigado pelo artigo, comecei a estudar sobre o BTRFS recentemente pelos snapshots, infelizmente o conteudo sobre não é tão vasto então tô quebrando cabeça pra entender a estrutura geral dele, sobre a criptografia nunca tinha pensado muito sobre mas agora vou seriamente ver sobre isso ja que o perigo de ter meu note roubado é real(perigoso por aqui).
tô querendo usar o BTRFS no meu manjaro (SSD 240GB pro SO e HD 1TB pros arquivos) nessa caso os dois discos precisariam ser criptografados?


Depende do seu nível de paranoia. Minha recomendação a você é mandar montar o seu hdd de 1TB como o /home criptografado. Se você decidir não criptografar o sistema, eu recomendo que pelo menos você mande montar o /tmp na RAM, assim tudo que tiver lá será limpo ao desligar o PC.


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