Então, um fornecedor que realmente não sabe que * nix tem um gerenciador de serviços e um agente para hosts da família Red Hat. (Ou seja, o vendedor não é de nenhuma ajuda, aqui.)
No Oracle Linux 7 com o SELinux Enforcing, posso iniciar este gerenciador de serviços e agente manualmente sem nenhum problema. O agente se conecta ao seu servidor, tudo é bom.
Eu criei um arquivo de unidade para systemd . Através de systemctl , o gerenciador de serviços começa bem, e journalctl mostra um bom começo. No entanto, quando o gerenciador de serviços tenta iniciar o agente, o agente falha. Se eu olhar no log do agente, o agente reportará esse erro:
Access to key store './agent.keystore' not possible
Originalmente, /var/log/audit/audit.log me mostrou 16 linhas de mensagens, incluindo várias mensagens SELINUX_ERR . Depois de tentar
chcon --type init_exec_t \
/path/to/agent \
/path/to/agent.ini \
/path/to/agent.keystore
Reduzi as mensagens do SELinux para essas quatro linhas:
type=SERVICE_START msg=audit(1490115506.797:14942): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=[UNIT NAME] comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SELINUX_ERR msg=audit(1490115506.818:14943): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:init_t:s0 newcontext=system_u:system_r:unconfined_service_t:s0
type=SYSCALL msg=audit(1490115506.818:14943): arch=c000003e syscall=59 success=yes exit=0 a0=55b4fd411540 a1=55b4fd3ee990 a2=55b4fd3223b0 a3=ffffffe0 items=0 ppid=1 pid=23199 auid=4294967295 uid=21908 gid=1040 euid=21908 suid=21908 fsuid=21908 egid=1040 sgid=1040 fsgid=1040 tty=(none) ses=4294967295 comm="[SERVICEMGR]" exe="[/PATH/TO/SERVICEMGR]" subj=system_u:system_r:init_t:s0 key=(null)
type=PROCTITLE msg=audit(1490115506.818:14943): proctitle=[REALLY LONG HEX STRING]
ls -Z no diretório afetado é
-rwsr-xr-x. root appuser unconfined_u:object_r:init_exec_t:s0 agent
-rw-r-----. appuser appuser unconfined_u:object_r:init_exec_t:s0 agent.ini
-r--------. root root unconfined_u:object_r:init_exec_t:s0 agent.keystore
Expandir as permissões de leitura no armazenamento de chaves não altera as mensagens de erro.
Portanto, o chcon reduziu a carga de falha do SELinux, mas não a eliminou. Ainda recebo as mensagens "acesso ao keystore não possível" no log do agente. Eu não encontrei nada útil sobre o que fazer sobre aquele determinado SELINUX_ERR , até agora.
Alguém já resolveu o desafio SELINUX_ERR op=security_bounded_transition ?
UPDATE 1: aqui está ls -Z para o gerenciador de serviços:
-rwxr-xr-x. appuser appuser unconfined_u:object_r:usr_t:s0 servicemgr
UPDATE 2:
Eu tentei alterar servicemgr para o tipo de arquivo init_exec_t para nenhuma alteração no comportamento. Eu já mudei de volta para usr_t . Meu palpite agora é que alterar os arquivos do agente para init_exec_t resolveu parte do problema, pois reduzi minhas mensagens de erro em 75%. O que eu estou pensando agora é que eu preciso identificar um tipo de arquivo SELinux que seja legível pelo contexto do arquivo init_exec_t .
UPDATE 3:
Depois de olhar as anotações do @Jakuje, abaixo, eu olhei para semanage fcontext -l . Não estou surpreso que unconfined_service_t não exista na lista. Arquivos que parecem não ter contexto específico reservado para eles parecem acabar com usr_t . Eu não sei como usr_t se relaciona com unconfined_service_t .
Criei políticas personalizadas no passado com a ajuda de sealert e do Google. Se eu precisar criar uma política personalizada para executar esses binários, tudo o que preciso é um bom tutorial para começar. O Google não ajudou em nada para isso. Uma coisa que precisa acontecer é que security_bounded_transition precisa ser trabalhado. Então, seja qual for o contexto em que eu criar ou terminar, init_t precisa não engasgar à medida que transita.