Algumas negações no SELinux (às vezes frustrantes) não são auditadas no registro de auditoria.
Eu estaria interessado em saber se você também experimenta esse problema de nenhum dado que ocorre se você executar semanage dontaudit off .
Isso mudará as regras do SELinux para até mesmo auditar as regras dontaudit . Note que pode ser muito chatty mantendo isso.
Observe também que DAC (permissões tradicionais do sistema de arquivos) são verificadas antes do MAC (SELinux, neste caso), portanto, se o problema é o caminho não é permitido, ou um diretório na árvore de caminho não permite isso devido às propriedades do arquivo ou modos, então você não receberá um relatório sobre isso.
Além disso, ao pesquisar o log de auditoria, use ausearch . Uma regra que deve abranger todos os resultados atribuídos ao SELinux seria:
ausearch -m avc -m user_avc -m selinux_err
O avc relata problemas de permissão padrão do SELinux, como quando a política não permite, user_avc relata erros do AVC do espaço do usuário, como dbus ou systemd e selinux_err relata erros com 'superpolicy', como onde normalmente, o tipo é permitido, mas a função não é permitida para o tipo - ou a função é permitida, mas o usuário não é permitido nessa função.
Papéis e usuários geralmente são encobertos no SELinux, já que muitas vezes não são utilizados, mas existe uma fraca possibilidade de que um problema possa surgir por causa deles.
Então, se você sentir que o problema está relacionado com o SELinux - isso ajudará a identificar o problema.
Para evitar total dúvida (e onde o sistema é insubstancial o suficiente para garantir isso) você pode executar setenforce 0 para desabilitar o SELinux e tentar saber com certeza se o problema está relacionado ao SELinux. Você pode setenforce 1 quando terminar. Mas note que os problemas de 'superpolicy' ainda falharão neste caso, pois são causados por erros de tempo de execução da política que tenta definir rótulos que não existem.