SELinux redefinir senha de root

Isenção de responsabilidade: Esta pergunta não é para resolver o problema de alterar a senha de root enquanto o SELinux está ativo, porque já existem muitos guias para resolver isso. É mais como o SELinux faz isso internamente.

Sou um usuário recente do SELinux, mas ultimamente tenho estado mais em contato com ele. Houve um momento em que alguém me perguntou como eu poderia redefinir a senha root em caso de esquecê-la.

Então eu iniciei meu CentOS, editei a entrada do grub para algo como

linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash

Eu corri passwde depois corri synce forcei a reinicialização. Após a reinicialização, o login com a nova senha foi rejeitado, assim como com a antiga, é claro.

Reiniciou novamente e passou ao kernel o parâmetro para desativar o SELinux ( selinux=0). Tentei fazer login com a nova senha e funcionou. Depois forcei uma nova identificação automática do fs (via arquivo .autorelabel) e, com o SELinux ativo, agora era possível efetuar login.

Minha pergunta é: por que acontece? Por que a mudança de nome afeta o logon quando houve apenas uma alteração de senha e não de usuários ou objetos?

Obrigado pela sua atenção.

TL; DR: A redefinição de senha root comum não funciona no SELinux. Por quê?

Edit: Isso foi testado em uma máquina virtual executando o CentOS7 com o KVM como hypervisor.

— Jorge Heleno
fonte

Tem certeza de que não funciona? Tente de novo. Provavelmente vai funcionar bem. Suspeito que você simplesmente tenha contextos de arquivo incorretos em alguns arquivos, causando falha em todos os logons. Assim, o autorelabel foi o que realmente corrigiu o problema.

— Michael Hampton

@MichaelHampton Acabei de refazer todos os meus passos fazendo isso de novo e não consegui entrar novamente com o SELinux ativo. Depois de desabilitá-lo, eu poderia fazer login sem problemas. Corrija-me se estiver errado, mas alterar uma senha não deve alterar o contexto do arquivo, certo?

— Jorge Heleno

Não, não deveria. Você parece ter descoberto algo estranho e inesperado.

— Michael Hampton

Consegui duplicar esse problema em um sistema CentOS 7.5 recém-instalado.

Eis aqui o que está acontecendo:

Quando você inicializa, init=/bin/bashhá dois problemas que podem ocorrer:

O sistema de arquivos raiz pode ser montado somente para leitura. Neste caso, passwdirá reclamar de um Authentication token manipulation error.

Isso é bastante óbvio: se o sistema de arquivos não estiver montado, leitura e gravação, não será possível gravar nele.
A política do SELinux pode não estar carregada. Nesse caso passwd, a senha será alterada com êxito, mas você terá o problema descrito na pergunta original acima: ninguém poderá fazer login.

Os hashes de senha são armazenados no /etc/shadowarquivo. Este arquivo normalmente possui o tipo SELinux shadow_t. No entanto, alterar o arquivo enquanto nenhuma política do SELinux está carregada faz com que o tipo SELinux seja removido do arquivo, deixando-o como unlabeled_t. Portanto, os serviços que tentam ler o arquivo para autenticar logons não conseguem mais lê-lo.

Para alterar a senha root no RHEL / CentOS 7, você precisa seguir este processo:

Adicione init=/bin/bashao final da linha de comando do kernel no grub, como você fez anteriormente.
No prompt do bash, carregue a política do SELinux com /usr/sbin/load_policy -i.
Monte o sistema de arquivos raiz para leitura e gravação mount -o remount,rw /.
Agora mude a senha e ela será bem-sucedida. passwd root
Remonte o sistema de arquivos somente para confirmar as alterações e ter um sistema de arquivos limpo na próxima inicialização com mount -o remount,ro /.
Saia do shell ou reinicie o sistema com exec /sbin/init 6.

Agora você pode fazer login com a senha root alterada.

Uma explicação mais detalhada deste procedimento está disponível na Red Hat (é necessária uma assinatura).

— Michael Hampton
fonte

O problema estava nas políticas que não foram carregadas. Por que eles não são carregados? O SELinux deve operar no nível do kernel, para que o sistema init não seja necessário.

— Jorge Heleno

@JorgeHeleno O SELinux está realmente ativado ou desativado por padrão quando o kernel é iniciado, mas a área do usuário é responsável por decidir quais políticas serão carregadas. O kernel não pôde decidir isso, porque algumas instalações podem querer políticas diferentes (por exemplo, direcionadas, estritas, mls). Isso acontece no início do processo de inicialização, mas você ignora isso ao executar init=/bin/bash.

— Michael Hampton

se uma política não é carregada, por que passwd"parece ter sucesso"?

— Andrew Savinykh

e se não teve êxito, por que o login com a senha antiga ainda falhou?

— Lightness Races em órbita

@ Jorge Helen: Sua explicação está quase completa. O ponto é que os arquivos são alterados, a passwdsaber, /etc/passwde /etc/shadow. Se estiver executando passwdsem política carregada, não será executado no contexto apropriado do selinux, e os arquivos alterados terminarão com um contexto diferente do selinux. Ao inicializar com o selinux ativado e as políticas ativas, a verificação de senha falha devido ao contexto inadequado do arquivo e não ao wrong passworderro. Forçar o selinux a reativar os arquivos de texto tocando /.autorelabeltambém pode corrigir esse problema ao alterar senhas sem a política carregada.

— hargut