SELinux interferindo com sss_cache

Sistema:

• Portátil HP Pavilion Power 15-cb0xx
• Intel i7-7700HQ com gráficos integrados habilitados (não pode ser desligado na bios)
• Fedora 28
• NVIDIA GTX 1050 (móvel)

Usei a dnfdragoraGUI para atualizar cerca de 119 pacotes (esqueci de atualizar por um tempo :/). Em algum momento, recebi uma notificação do SELinux:

SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/

Vasculhei /var/log/messagese /var/log/audit/audit.logencontrei as mesmas coisas que o SELinux me disse.

Depois que tudo isso aconteceu, percebi que as coisas estavam indo devagar, então reiniciei. A reinicialização foi mais lenta, particularmente óbvia quando o logotipo do Fedora estava carregando, quando a GUI de login estava carregando e quando a área de trabalho estava carregando. Uma reinicialização adicional não corrigiu nada.

Olhando para a página de manual sss_cache, recebo a essência do que ele faz e que funciona com o System Security Services Daemon (SSSD).

Isto é o que a caixa de diálogo do SELinux está me dizendo:

Eu entendo que isso notificará os mantenedores de um possível bug, e as mudanças de política impedirão que o SELinux alerte no sss_cache no futuro. Eu não sei nada sobre o SELinux além de fornecer adições de segurança adicionadas/configuráveis ​​para um sistema Linux. No entanto, ainda não entendo por que isso aconteceu, ou se existem outras soluções potencialmente melhores. Também não está claro para mim se isso esclarecerá os problemas de desaceleração que notei.

Alguém pode me dizer:

1. Por que isso pode ter acontecido? Eu posso adivinhar que o SELinux considera qualquer coisa associada ao SSSD como muito importante para proteger, mas por que ele não está ciente de um utilitário destinado a funcionar com o SSSD?
2. Devo apenas relatar o bug e criar o módulo de política local ou outra coisa?
3. Devo desfazer a transação que levou a tudo isso e atualizar os pacotes em grupos menores? Seria mesmo desfazer o problema?
4. Isso poderia ter causado os problemas de lentidão que observei acima? Eu sei por trabalhar com VMs (especificamente expandindo o espaço de armazenamento no VirtualBox) que deixar uma entrada antiga /etc/fstabpode retardar a inicialização porque o sistema está procurando por algo que não existe. Está acontecendo algo semelhante aqui?

Eu sou relutante em apenas fazer o que as palavras na tela dizem sem informações adicionais. Não quero colocar um band-aid em uma cratera de bomba sem perceber.

(Informações adicionais conforme solicitado): Eu deveria ter declarado: /var/lib/sss/db/é um diretório.

ls -Z /var/lib/sss/saída para db/:system_u:object_r:sssd_var_lib_t:s0

Trecho de audit.log(inclui uma linha potencialmente não relacionada entre duas linhas relevantes):

type=AVC msg=audit(1543865969.237:241): avc:  denied  { write } for  pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc:  denied  { write } for  pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0

Saída de ls -Z /usr/sbin/sss_cache(localização encontrada via which sss_cache):

system_u:object_r:bin_t:s0

Acontece que a janela "detalhes" tinha muitas informações: