SELinux woes desenvolvendo extensão systemd

Question

Tudo,

Estou desenvolvendo uma modificação no systemd que estenderá o systemd-sleep para suportar a chamada de scripts definidos pelo usuário em suspensão, suspensão híbrida, etc., semelhante ao systemd-sleep. Isso está funcionando muito bem, no entanto, quando comecei a testar em um sistema habilitado para o SELinux, as coisas começaram a desmoronar.

Eu não sou bem versado no SELinux, então não tenho certeza sobre onde começar a procurar. Fundamentalmente, o serviço chama um script como um usuário configurado (/ usr / lib / systemd / systemd-sleep-user) que, por sua vez, executa qualquer executável em $HOME/.config/systemd/system-sleep .

A mensagem de erro associada é: SELinux is preventing systemd-sleep-u from execute_no_trans access on the file /home/stallion/.config/systemd/system-sleep/kill-scdaemon.sh.

Como esse comportamento é semelhante ao funcionamento do systemd-sleep (embora ele use / usr / lib / systemd / system-sleep), esperava que isso apenas exigisse a aplicação das mesmas propriedades ao local do usuário.

Alguma opinião?

Editar : entrada do registro de auditoria relevante abaixo:

type=AVC msg=audit(1508702442.885:388): avc: denied { execute_no_trans } for pid=3539 comm="systemd-sleep-u" path="/home/stallion/.config/systemd/system-sleep/kill-scdaemon.sh" dev="dm-3" ino=533984 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=0

    

Answer 1

O erro ocorre porque não há uma regra na política do SELinux para permitir o acesso específico: permitir a execução sem transição de um arquivo com o contexto config_home_t por um processo em execução em init_t domínio.

Você poderia criar um módulo de política personalizado para incluir essa regra, mas provavelmente não permitiria que qualquer processo de inicialização executasse qualquer arquivo com o rótulo de dados de usuário. Outra opção é criar uma política personalizada que contenha um novo contexto de arquivo para seus scripts, regras de rotulagem correspondentes e regras que permitam um processo no domínio init_t executá-los.

Terceira opção (e provavelmente a opção mais simples) é configurar o systemd para executar o processo em domínio não confinado , no qual o SELinux praticamente não impõe restrições (restrições regulares de DAC, etc. ainda se aplicam). Use a opção SELinuxContext no seu arquivo de serviço systemd:

SELinuxContext=system_u:system_r:unconfined_t:s0