Movido / home para novo disco, SELinux negando acesso a / home para sshd

Question

Ontem adicionei uma unidade a uma caixa da VM Centos6, criei um ponto de montagem / home na unidade e movi um usuário (Jenkins, neste caso) para liberar espaço do / ponto de montagem.

Isso pareceu funcionar bem, e todas as permissões e rótulos parecem corretos, mas hoje cedo comecei a ver os problemas em que não era possível usar o SSH na caixa como o usuário do jenkins em qualquer caixa. SSH para a caixa como root e su ing para jenkins funcionaram bem. Além disso, se eu fizesse um service sshd stop e, em seguida, /usr/sbin/sshd , eu poderia me conectar diretamente à caixa como o usuário do jenkins.

Depois de muita depuração, acabei descobrindo negações do SELinux em /var/log/audit/audit.log da seguinte forma:

type=AVC msg=audit(1428584552.564:187): avc:  denied  { search } for  pid=1798 comm="sshd" name="/" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=AVC msg=audit(1428584552.567:188): avc:  denied  { getattr } for  pid=1798 comm="sshd" path="/home" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

Definir o SELinux como permissivo, em seguida, permitiu que eu me reconectasse como o usuário do jenkins remotamente.

Eu não sou muito bom com o SELinux, mas depois de ler (novamente) os tutoriais do Gentoo sobre o SELinux Eu li esses erros como sshd tentando acessar ambos / e / home com um contexto do sistema de system_u:system_r:sshd_t:s0 . Em vez disso, esses pontos finais são rotulados como system_u:object_r:file_t:s0 , que é pelo menos o que o diretório / home é rotulado como (não muito certo como ver o rótulo para /).

Para mim, esses rótulos parecem corretos para esses diretórios e não sei muito bem por que ele está tentando procurar um rótulo sshd_t até agora na árvore de diretórios.

A execução de ls -laZ para obter as partes importantes (pasta .ssh e authorized_keys) me dá:

drwx------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 .ssh

e

-rw-------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 authorized_keys

Que parece o mesmo que as outras caixas que estou verificando e elas funcionam bem.

O que preciso fazer para que o SELinux coopere para que eu possa voltar a aplicar?

EDIT: Tentei desmontar / home e usar o restorecon para tentar reclassificar o diretório graças à sugestão de Michael Hampton mas isso não alterou o rótulo no diretório e, como mencionado acima, o rótulo system_u:object_r:file_t:s0 de / home parece correto quando comparado a outras caixas que estão funcionando bem.

Existe uma maneira de alterar o contexto do sistema do sshd ao tentar acessar este diretório?

    

Answer 1

Você não está olhando para os diretórios corretos.

Suas recusas de AVC estão reclamando especificamente sobre os contextos em / e /home , respectivamente, e não em qualquer arquivo dentro deles.

Isso me faz suspeitar que você tenha mais do que apenas as entradas de diretório com etiquetas erradas.

É assim que eu recupero:

1. Desmontar /home . Isso é necessário porque queremos restaurar o contexto do arquivo no ponto de montagem no sistema de arquivos pai, bem como os contextos do arquivo dentro do sistema de arquivos filho.

2. Restaurar contextos de arquivo para o ponto de montagem /home .

   restorecon -v /home
   

3. Remontar /home .

4. Restaure os contextos dos arquivos para todo o sistema, apenas para ter certeza. Isso pode ser feito de duas maneiras:

   • touch /.autorelabel e reinicialize. O sistema será reclassificado durante a inicialização.
   • restorecon -r -v / e reinicialize quando terminar. Eu costumo usar esse método, pois ele fornece uma lista completa dos contextos de arquivos que foram alterados.

Uma vez que você tenha sido renomeado e reiniciado, você deve estar seguro para retornar à aplicação do SELinux.