< Dm-crypt (Português)

dm-crypt (Português)/System configuration (Português)

Status de tradução: Esse artigo é uma tradução de Dm-crypt/System configuration. Data da última tradução: 2021-02-15. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.
Dica:

mkinitcpio

Em alguns cenários, um subconjunto dos seguintes hooks do mkinitcpio terão que ser habilitados:

busyboxsystemdCaso de uso
encrypt sd-encrypt Sempre necessário quando a partição raiz, ou outra partição que precisa ser montada antes dela, é criptografada. Não é necessário em todos os casos, scripts de inicialização de sistema como crypttab cuidam do desbloqueio de outras partições criptografadas. Deve ser colocado depois do hook udev ou systemd.
keyboard Necessário para o funcionamento do teclado no estágio inicial do espaço do usuário.
keymap Trás suporte a teclados que não são do padrão US; deve ser colocado antes do hook encrypt. Defina seu padrão do seu teclado em , veja Configuração de teclado no console#Configuração persistente.
Carrega uma fonte alternativa para o console no estágio inicial do espaço do usuário. Defina sua fonte em , veja Console do Linux#Configuração persistente.

Outros hooks necessários devem ser claramente especificados durante a instalação do sistema.

Gere novamente o initramfs depois de salvar as mudanças.

Exemplos

Uma configuração típica em quando se usa o hook encrypt é:

/etc/mkinitcpio.conf
...
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt lvm2 filesystems fsck)
...

Já uma configuração com o initramfs baseado no systemd, fazendo uso do hook sd-encrypt, seria semelhante a:

/etc/mkinitcpio.conf
...
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt lvm2 filesystems fsck)
...

Gerenciador de boot

Para habilitar a inicialização em uma partição raiz criptografada, um subconjunto dos seguintes parâmetros do kernel terão que ser configurados. Veja Parâmetros do kernel para instruções específicas para seu Gerenciador de boot.

Por exemplo, se está usando o GRUB, os parâmetros relevantes são adicionados no , antes de gerar o arquivo de configuração principal. Veja também GRUB#Aviso ao instalar em chroot como outro ponto a se atentar.

Os parâmetros do kernel irão variar de acordo com qual hook (encrypt ou sd-encrypt) você vai usar.

Parâmetros do Kernel

Parâmetros do kernel como e são especificados da mesma forma para os hooks encrypt e sd-encrypt.

root

O parâmetro especifica o do sistema de arquivos raiz (descriptografado):

root=dispositivo
  • Se o sistema de arquivos foi colocado diretamente no dispositivo descriptografado, o caminho será .
  • Se LVM vai ser ativado primeiro e contém um volume lógico raiz criptografado, a forma acima também é aplicável.
  • Se o sistema de arquivos raiz está no volume lógico de uma LVM criptografada, o mapeador de dispositivos vai estar em sua forma genérica .

resume

resume=dispositivo
  • nesse caso é a swap descriptografada, este parâmetro é utilizado com o objetivo de suspender para o disco. Se a swap está em uma partição separada, ela estará na forma de /dev/mapper/partição_swap. Veja também dm-crypt/Swap criptografada.

Usando o hook encrypt

Nota: Comparado com o hook sd-encrypt, o hook encrypt não suporta:

cryptdevice

Este parâmetro fará o sistema solicitar a senha para abrir o dispositivo contendo a raiz criptografada na primeira inicialização (cold boot). Ele é utilizado para o hook encrypt identificar o dispositivo que contém o sistema criptografado:

cryptdevice=dispositivo:nomedm
  • é o caminho para o container criptografado que contém o sistema. É fortemente recomendado o uso de nomeação persistente de dispositivo de bloco.
  • é o nome do dispositivo mapeado que será dado ao container descriptografado, que estará disponível como .
  • Se possui um volume lógico raiz criptografado, LVM vai ser ativado primeiro, o grupo de volumes e o volume lógico raiz serão o dispositivo. Coloque da seguinte forma .

cryptkey

Este parâmetro especifica a localização de uma keyfile, o hook é necessário para ler e abrir o (a menos que a chave está em um caminho padrão, veja abaixo). Três parâmetros podem ser definidos, dependendo de como a keyfile existe, pode ser um arquivo no dispositivo, uma bitstream que começa em uma localização específica ou um arquivo incluido no initramfs.

Para um arquivo no dispositivo o formato é:

cryptkey=dispositivo:tipo_do_sistema_de_arquivos:caminho
  • é o dispositivo de bloco onde a keyfile se encontra. Uso de nomeação persistente de dispositivo de bloco é fortemente recomendado.
  • é o tipo do sistema de arquivos do (ou auto).
  • é o caminho absoluto da keyfile dentro do dispositivo.

Exemplo:

Para uma bitstream no dispositivo, a localização é especificada com:

cryptkey=dispositivo:início:tamanho 

Onde início e tamanho estão em bytes. Por exemplo, cryptkey=UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ:0:512 lê uma keyfile de 512 byte no começo do dispositivo.

Para um arquivo incluído no initramfs o formato é:

cryptkey=rootfs:caminho

Exemplo:

Também note que se cryptkey não é especificada, o padrão (arquivo incluído no initramfs) será utilizado.

Veja também dm-crypt/Encriptação de dispositivo#Keyfiles.

crypto

Este parâmetro é especifíco para passar opções do modo plain do dm-crypt para o hook encrypt.

Sua forma é:

crypto=<hash>:<cifra>:<tamanho_da_chave>:<início>:<pule>

Os argumentos são relacionados diretamente a opções do cryptsetup. Veja dm-crypt/Encriptação de dispositivo#Opções de encriptação para o modo plain.

Para um disco criptografado com somente as opções padrão do modo plain, o argumento deve ser especificado, mas cada entrada pode ser vazia:

crypto=::::

Um exemplo especifíco é:

crypto=sha512:twofish-xts-plain64:512:0:

Usando o hook sd-encrypt

Todos os seguintes podem ser trocados por . Os parâmetros são somente reconhecidos pelo initrd, enquanto são reconhecidos tanto pelo sistema quanto pelo initrd. A menos que você queira controlar os dispositivos com argumentos dados ao kernel enquanto o sistema é inicializado, use . Veja para mais informações e detalhes.

Atenção: Se você está usando o /etc/crypttab ou /etc/crypttab.initramfs junto com os parâmetros luks.* ou rd.luks.*, somente os dispositivos especificados na linha de comando do kernel serão ativados e você verá Not creating device 'devicename' because it was not specified on the kernel command line.. Para ativar todos os dispositivos em /etc/crypttab não especifique nenhum parâmetro luks.* e use rd.luks.*. Para ativar todos os dispositivos em /etc/crypttab.initramfs não especifique nenhum parâmetro luks.* or rd.luks.*.

rd.luks.uuid

rd.luks.uuid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Especifique o UUID do dispositivo a ser aberto na inicialização com este parâmetro. Se o UUID está em , as opções listadas lá serão utilizadas. Para opções do , o ou será usado.

Por padrão o dispositivo mapeado estará localizado en /dev/mapper/luks-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX onde XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX é o UUID da partição LUKS.

rd.luks.name

rd.luks.name=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=nome

Especifique o nome do dispositivo mapeado depois que a partição LUKS é aberta, onde XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX é o UUID dela. É equivalente ao segundo parâmetro do encrypt, .

Exemplo, especificar faz o dispositivo LUKS aberto do UUID estar localizado em .

rd.luks.options

rd.luks.options=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=opções

ou

rd.luks.options=opções

Defina as opções para um dispositivo especificado com o UUID ou, se não especificado, para todos os UUIDs especificados em outro lugar (e.g., crypttab).

É relativamente equivalente ao terceiro parâmetro do encrypt, .

Segue um formato similar às opções usadas no crypttab - opções são separadas por vírgulas, opções com valores são especificados com .

Exemplo:

rd.luks.options=timeout=10s,swap,cipher=aes-cbc-essiv:sha256,size=256

rd.luks.key

Especifique a localização da keyfile que será utilizada para abrir o dispositivo especificado com o UUID. Não há uma localização padrão para a keyfile, como existe com o parâmetro do hook encrypt, cryptkey.

Se a keyfile está incluída no initramfs:

rd.luks.key=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=/caminho/para/keyfile

ou

rd.luks.key=/caminho/para/keyfile

Se a keyfile está em outro dispositivo:

rd.luks.key=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=/caminho/para/keyfile:UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ

Substitua com o identificador do dispositivo que a keyfile está localizada. Se o sistema de arquivos utilizado não é o mesmo do sistema raiz, você deve incluir o módulo dele no initramfs.

Timeout

Existem duas opções que irão afetar o tempo de espera até a senha ser solicitada durante a inicialização:

  • especifica o tempo máximo para achar a senha
  • especifica o quanto systemd deve esperar pelo dispositivo até desistir (padrão 90 segundos)

Se deseja desabilitar os tempos de espera, então defina ambos para zero:

rd.luks.options=timeout=0 rootflags=x-systemd.device-timeout=0

crypttab

O arquivo (tabela de dispositivos criptografados) é similar ao arquivo fstab e contém uma lista de dispositivos criptografados que serão abertos durante a inicialização. Este arquivo pode ser usado para montar automaticamente dispositivos swap ou sistemas de arquivos não raiz.

crypttab é lido antes do fstab, então os containers do dm-crypt podem ser abertos antes que o sistema de arquivos seja montado. Note que crypttab é lido depois que o sistema inicia, logo não é um substituto para abrir partições criptografadas com os hooks do mkinitcpio e opções do gerenciador de boot como no caso de criptografar a partição raiz. A leitura do crypttab é feita na inicialização pelo automaticamente.

Veja para detalhes, veja abaixo alguns exemplos, e a seção #Montando na inicialização para instruções de como usar UUIDs para montar um dispositivo criptografado.

Atenção:
  • Se a opção nofail é especificada, a tela de entrada da senha pode desaparecer enquanto digita. nofail deve então somente ser usada junto com keyfiles.
  • Existem problemas no systemd quando ele processa entradas do crypttab para o modo plain (--type plain) do dm-crypt:
    • Para dispositivos --type plain com uma keyfile, é necessário adicionar a opção hash=plain para o crypttab devido a uma incompatibilidade do systemd. Não use systemd-cryptsetup manualmente para a criação do dispositivo como medida provisória.
    • Pode ser necessário adicionar a opção plain explicitamente para forçar systemd-cryptsetup a reconhecer o dispositivo (--type plain) na inicialização. Veja issue do systemd 442.

Para testar seu crypttab imediatamente depois de editá-lo, recarregue o gerenciador de configuração do systemd com:

# systemctl daemon-reload

e inicie o recentemente gerado .

Para mais informações sobre , veja #Montando em demanda.

Montando na inicialização

Se você quer montar uma unidade de armazenamento criptografada na inicialização, você pode colocar o UUID do dispositivo em . Para descobrir o UUID (da partição) pode usar o comando e adicioná-lo ao crypttab desse jeito:

O primeiro parâmetro é o nome que o dispositivo criptografado vai receber quando aberto(que fica a sua preferência). A opção none fará a senha ser solicitada durante a inicialização. A opção define um tempo de espera máximo em segundos para entrar com a senha.

Desbloqueando com uma keyfile

Se a keyfile para um sistema de arquivos não raiz está guardada dentro do sistema criptografado, ela está segura quando o sistema está desligado e pode ser automaticamente aberto durante a inicialização via crypttab. Por exemplo, abrir um dispositivo especificado com UUID:

Dica:
  • Se uma keyfile não é especificada, systemd-cryptsetup(8) irá automaticamente tentar carregá-la de /etc/cryptsetup-keys.d/nome.key e /run/cryptsetup-keys.d/nome.key.
  • Se você prefere usar o modo --plain, as opções de encriptação necessárias para abrir o dispositivo deverão ser especificadas no /etc/crypttab. Tome cuidado ao fazer a medida provisória mencionada no crypttab.

Use o nome do dispositivo mapeado (definido no ) para fazer a entrada no :

Desde que já é uma mapeação única, não existe a necessidade de especificar o UUID dele. Em qualquer caso, o sistema de arquivos mapeado vai ter um UUID diferente da partição criptografada.

Montando um dispositivo de bloco empilhado

Os geradores do systemd também processam automaticamente os dispositivos de bloco empilhados na inicialização.

Por exemplo, você pode usar o cryptsetup numa configuração do RAID e criar um volume lógico LVM com o sistema de arquivos dentro de um dispositivo de bloco criptografado. Resultando em:

A senha será solicitada e ele será montado na inicialização.

Ao especificar corretamente as entradas do crypttab (exemplo, UUID para o dispositivo ) e fstab (), não há necessidade para configurações/hooks adicionais no mkinitcpio, devido ao processamento do aplicado às partições não raiz somente. Existe uma exceção, quando o hook mdadm_udev é usado (exemplo, o dispositivo raiz). Neste caso é necessário atualizar o e o initramfs para que a raid raiz correta seja selecionada.

Montando em demanda

Ao invés de:

# cryptsetup luksOpen UUID=... disco_externo

Você pode iniciar o , quando você tem uma entrada como a seguir em seu :

Desta maneira você não precisa se lembrar exatamente das opções do crypttab. A senha será solicitada se necessário.

O arquivo correspondente unit é gerada automaticamente pelo . Você pode listar todos os arquivos unit gerados usando:

$ systemctl list-unit-files | grep systemd-cryptsetup

Solução de problemas

Sistema travado no prompt de inicialização/senha não aparece

Se você está usando Plymouth, tenha certeza de usar os módulos corretos (veja Plymouth#O hook do plymouth) ou desabilite isso. De outra forma, Plymouth irá atrapalhar o prompt de senha, impedindo o sistema de inicializar.

gollark: Is histodev GDPR-compliant?
gollark: <@356107472269869058> rust.
gollark: <@330678593904443393> The bees are all stored in a single backing array, but mapped onto hexagonal structures when displayed.
gollark: Deploying orbital bee array.
gollark: Stop being so deterministic, you triskaidecagon.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.