Jump to content
From ArchWiki

Artigos relacionados

- fscrypt
- Segurança
- PAM
- Usuários e grupos

Status de tradução: Esse artigo é uma tradução de Systemd-homed. Data da última tradução: 2020-07-15. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

systemd-homed é um serviço do systemd que fornece contas de usuário humanas e que são independentes da configuração atual do sistema.

Ele permite portabilidade ao poder mover todas as informações relacionadas ao usuário para um meio de armazenamento, opcionalmente criptografado, e cria um arquivo `~/.identity` que contém informação com assinatura sobre o usuário, senha, quais grupos o usuário pertence, UID/GID e outros arquivos que estariam dispersas em vários arquivos no `/`.

Esta abordagem permite não apenas portabilidade do diretório pessoal do usuário, mas também fornece segurança gerenciando a criptografia do `/home` ao se autenticar com o usuário e também ao suspender a máquina pois a pasta é bloqueada novamente.

Nota: Forget key on suspend não é suportado. Está marcado como TODO para o GNOME

## Instalação

systemd-homed é parte do systemd e portanto, vem empacotado junto ao pacote.

Para utilizar o systemd-homed, você deve habilitar e iniciar o `systemd-homed.service`.

## Utilitários

### homectl

`homectl` é o principal utilitário que você irá utilizar. Com ele, você pode criar, atualizar e inspecionar usuários; os diretórios pessoais destes; assim como os arquivos `~/.identity` controlados pelo serviço systemd-homed(8).

A maneira mais simples de utilizar o homectl é:

    # homectl create nome-do-usuário

Este comando irá criar o nome específico do usuário, utilizando um UID livre, criará um grupo com o mesmo nome, e GID igual ao UID, definirá o usuário como membro deste grupo, e definirá o shell padrão do usuário como `/bin/bash`.

O diretório pessoal do usuário é montado em `/home/nome-do-usuário`. O mecanismo de armazento é escolhido nesta ordem:

1. `luks` se houver suporte;
2. `subvolume` se não houver suporte a LUKS e houver suporte a subvolume;
3. `directory` (diretório) se não houver suporte a nenhum dos dois mecanismos acima e outra opção não for escolhida.

O caminho do arquivo de imagem do usuário quando utilizado com LUKS é `/home/nome-do-usuário.home`. O caminho do arquivo de imagem do usuário quando utilizado com diretório é `/home/nome-do-usuário.homedir`.

Nota: homectl não gerencia criação ou deleção de grupos, a não ser os próprios grupos que se igualam ao nome e ID dos usuários gerenciados pelo systemd-homed.
Atenção: Os arquivos `~/.identity` possuem assinatura, então não devem ser editados diretamente com um editor de texto, pois isto quebra a assinatura e torna o arquivo inválido. Use `homectl update --identity=/caminho/para/.identity` para modificar.

### userdbctl

Uma ferramenta de consulta para inspecionar usuários, grupos e membros de grupos fornecidos tanto por mecanismos clássicos de unix quanto por systemd-homed.

## Mecanismo de armazenamento

### Directory ou subvolume do Btrfs

Um diretório pessoal de usuário é armazenado em `/home/usuário.homedir` e montado em `/home/usuário` utilizando a opção `--bind` do mount(8) ao ser desbloqueado quando o usuário se autentica. Quanto este método é utilizado, nenhuma criptografia é fornecida. Para utilizar este mecanismo, utilize `--storage=directory` ou `--storage=subvolume` no comando `homectl`.

### Diretório pessoal com fscrypt

Um diretório pessoal de usuário é armazenado da mesma forma que o método acima, mas uma criptografia de sistema de arquivos nativa é usada. Para usar este mecanismo, utilize `--storage=fscrypt` no comando `homectl`.

Dica: fscrypt possui suporte a vários sistemas de arquivo, incluindo ext4 e F2FS

### Servidor CIFS

O diretório é montado à partir de um servidor CIFS (Common Internet File System - Sistema de arquivos comum da internet) ao autenticar. Note que CIFS é implementado pelo protocolo Samba. Utilize `--storage=cifs` no comando `homectl`. A senha local do usuário é utilizada para se autenticar ao serviço de CIFS.

### Diretório pessoal com LUKS

Um diretório pessoal do usuário é armazenado em um sistema de arquivos do Linux, dentro de um volume criptografado com LUKS (Linux Unified Key Setup - Configuração Unificada de Chaves do Linux) dentro de um arquivo loopback ou qualquer mídia removível. Para utilizar este mecanismo, use `--storage=luks` no comando `homectl`.

Se estiver utilizando uma mídia removível, assegure-se que estas condições são atendidas:

- A imagem contém uma tabela de particionamento em GPT. Por enquanto, deve apenas conter uma única partição, e esta partição deve ter o tipo `UUID 773f91ef-66d4-49b5-bd83-d683bf40ad16`. O rótulo da partição deve ser o nome do usuário.

- Esta partição deve conter um volume LUKS2, cujo rótulo deve ser o nome do usuário. O volume LUKS2 deve conter o campo de token do tipo systemd-homed. Os dados em JSON deste token devem ter um campo de registro, contendo um texto com dados codificados em base64. Este arquivo é o registro de usuário em JSON, com a mesma serialização que `~/.identity`, só que criptografado. Os dados em JSON deste token devem também ter um campo iv (initialization vector - vetor de inicialização), que contém um binário de vetor de inicialização codificado em base64 para a criptografia. A criptografia utilizada é a mesma que o próprio volume em LUKS2 usa, desbloqueada pela mesma key (chave) de volume, mas baseada no seu próprio IV.

- Dentro deste volume de LUKS2 deve haver um sistema de arquivos Linux, sendo um dos seguintes: EXT4, BTRFS e XFS. O rótulo do sistema de arquivos deve ser o nome do usuário.

- Este sistema de arquivos deve conter um único diretório, nomeado a partir do usuário, este diretório se tornará o diretório pessoal do usuário quando ativado. Ele contém uma segunda cópia do registro no arquivo `~/.identity`, como nos outros mecanismos de armazenamento.

## Habilitando módulos do PAM

Já que não existem registros de usuários do tipo systemd-homed em bancos de dados NSS do UNIX (como `/etc/passwd`, `/etc/shadow` e `/etc/group`), o módulo do PAM `pam_unix.so` não irá autorizar estes usuários sequer a autenticação para entrar no sistema. Portanto será necessário usar um módulo `pam_systemd_home.so`. Enquanto o usuário do systemd-homed estiver autenticado, o PAM sintetizará os registros NSS para ele.

Atenção: Erros na configuração do PAM podem quebrar os meios do sistema autorizar, impedindo o login até do usuário root. Fazer backup dos arquivos de configuração do PAM é recomendado antes que quaisquer mudanças sejam feitas.

Apenas um dos dois módulos irá permitir a autorização, então o PAM deve ser instruído para desconsiderar a falha do outro. Para isto ocorrer, é necessário um valor de controle chamado sufficient. porém, o valor de controle deste módulo, ao ocorrer com sucesso, fará com que o resto da pilha (stack) seja ignorada. Uma maneira de resolver isto, é através de uma subpilha (substack):

    /etc/pam.d/nss-auth

    #%PAM-1.0

    auth     sufficient pam_unix.so try_first_pass nullok
    auth     sufficient pam_systemd_home.so
    auth     required   pam_deny.so

    account  sufficient pam_unix.so
    account  sufficient pam_systemd_home.so
    account  required   pam_deny.so

    password sufficient pam_unix.so try_first_pass nullok sha512 shadow
    password sufficient pam_systemd_home.so
    password required   pam_deny.so

Substitua `pam_unix.so` no arquivo `/etc/pam.d/system-auth`, com a configuração criada utilizando o valor de controle substack:

    /etc/pam.d/system-auth

    #%PAM-1.0

    auth      substack   nss-auth
    auth      optional   pam_permit.so
    auth      required   pam_env.so

    account   substack   nss-auth
    account   optional   pam_permit.so
    account   required   pam_time.so

    password  substack   nss-auth
    password  optional   pam_permit.so

    session   required  pam_limits.so
    session   optional  pam_systemd_home.so
    session   required  pam_unix.so
    session   optional  pam_permit.so

Dica: Consulte pam_systemd_home(8) e pam.d(5) para mais informações em opções.

## Propriedades de registro de usuário

Consulte o registro completo de usuário com:

    # homectl inspect nome-do-usuário

Modifique ou acrescente no registro completo de usuário com:

    # homectl update nome-do-usuário --propriedade=VALOR

É possível modificar e acrescentar várias propriedades:

- `--timezone=FUSO-HORÁRIO`
- `--language=IDIOMA`
- `--member-of=GRUPO1,GRUPO2,GRUPO-N`
- `--real-name=NOME`
- `--email-address=EMAIL`
- `--ssh-authorized-keys=LINHA_COM_CHAVE_AUTORIZADA` ou `@/arquivo/com/chaves`

Consulte homectl(1) para mais opções.

## Gerenciando usuários

### Criação

Criação simples de um usuário com criptografia LUKS:

    # homectl create nome-do-usuário --storage=luks

Criação simples de um usuário com criptografia fscrypt:

    # homectl create nome-do-usuário --storage=fscrypt

Criação simples de um usuário com UID, shell e grupos específicos:

    # homectl create nome-do-usuário --shell=/bin/zsh --uid=1001 -G wheel,storage,games

Outras opções podem ser encontradas em homectl(1) § USER RECORD PROPERTIES.

### Deleção

Atenção: A deleção do usuário é instantânea, tenha cuidado!

É possível fazer a deleção de vários usuários ao mesmo tempo, como root, você pode rodar o comando abaixo que irá deletar os 2 usuários de uma única vez:

    # homectl remove nome-do-usuário1 nome-do-usuário2

## Desbloquear remotamente através de SSH

Para permitir que o serviço de SSH dependa de registros de usuários contendo as chaves autorizadas, o arquivo `sshd_config` precisa conter as seguintes linhas

    AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u
    AuthorizedKeysCommandUser root

Você pode receber a mensagem de erro `Home of user nome-do-usuario is currently not active, please log in locally first.`, neste caso, você precisa ativar o diretório pessoal do usuário com o comando `homectl activate nome-do-usuario`.

## Veja também

- https://systemd.io/HOME_DIRECTORY/

Category:

- Security (Português)