compgen e SELinux

Question

Eu tenho um aplicativo, shell do navegador e estou executando este comando para obter uma lista de execuables ( Listar todos os binários de $ PATH )

compgen -A function -abck | sort | uniq

e quando eu chamo este comando ele retorna executáveis, mas eu tenho muitos erros do SELinux como este:

SELinux is preventing bash from getattr access on the file /usr/sbin/chronyd.

allow this access for now by executing:
# ausearch -c 'bash' --raw | audit2allow -M my-bash
# semodule -X 300 -i my-bash.pp

existe uma maneira de evitar esse erro? Eu quero que meu aplicativo funcione no SELinux sem erros fora da caixa.

Eu posso mudar o PATH ou executar algum comando para verificar se o caminho pode estar na variável PATH, o que provavelmente o / usr / sbin não pode estar no PATH. Esse comando existe? Eu tenho este PATH por padrão:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games

este é o resultado de sudo ausearch -c 'bash' --raw

type=AVC msg=audit(1506851274.781:2921): avc:  denied  { getattr } for  pid=12298 comm="bash" path="/usr/sbin/xl2tpd" dev="sda1" ino=2239132 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:l2tpd_exec_t:s0 tclass=file permissive=1

e com | audit2why :

type=AVC msg=audit(1506851274.781:2921): avc:  denied  { getattr } for  pid=12298 comm="bash" path="/usr/sbin/xl2tpd" dev="sda1" ino=2239132 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:l2tpd_exec_t:s0 tclass=file permissive=1

    Was caused by:
        Missing type enforcement (TE) allow rule.

        You can use audit2allow to generate a loadable module to allow this access.

é possível fazer meu código funcionar sem o audit2allow ?

    

Answer 1

A política padrão fornecida com o SELinux é projetada para permitir o acesso típico do sistema para cada aplicativo. Ao contrário do seu shell de login regular, o seu "web shell" está sendo executado no contexto do servidor web ( link ) no qual as restrições para o servidor web se aplicam. Seu servidor da web também está sendo executado em um domínio permissivo , o que significa que as regras de política não são aplicadas, somente registradas, portanto você não vê erros de permissão negada em seu aplicativo.

A maneira mais simples de se livrar da mensagem seria seguir a sugestão de usar audit2allow , após o qual você pode definir link de volta ao modo de aplicação. audit2allow cria uma nova regra que permite o acesso específico para o qual a mensagem de negação foi gerada: uma regra para permitir o link getattr para arquivos com o contexto l2tpd_exec_t .

Se você planeja continuar usando um shell a partir do servidor web, é provável que você veja mais erros de permissão do SELinux quando você faz algo que a política padrão não permite (no contexto link ).

Idealmente, você deve criar uma política personalizada com um caminho de transição claro para um domínio (mais) permissivo no qual o shell é executado. Isso permite que você execute o shell não confinado sem conceder ao servidor da web acesso excessivamente permissivo. Se for útil, depende completamente dos detalhes de como o shell é lançado a partir do servidor web (scripts, etc).

Se você decidir manter link no modo permissivo de qualquer forma e não desejar mensagens de log, poderá configurar o servidor da Web para ser executado em um contexto não confinado. De qualquer forma, para o servidor da Web, isso é praticamente o mesmo que a execução do SElinux desativado .