systemd service - a difusão do udp não pode alcançar outra máquina

Question

Eu tenho um serviço localizado em / usr / lib / systemd / system. Este serviço executa o aplicativo que eu tenho desenvolvido (.net core 2.0). O mesmo aplicativo é executado em máquinas diferentes (centos7 ambos). Eles usam soquetes udp para se encontrarem.

Eu tenho testado este aplicativo há muito tempo antes de preparar o arquivo .service para eles e tudo estava funcionando muito bem. Eles conseguiram transmitir mensagens uns para os outros.

Quando o serviço executa o aplicativo, a única mensagem que a instância pode obter é aquela que a mesma instância estava transmitindo em primeiro lugar. Mesma situação nas outras máquinas. Eles podem ter suas próprias transmissões, mas não as do outro.

Desde que eu sou novo no linux e não sei onde procurar e o que devo procurar, eu vim através de algumas informações inúteis e é por isso que eu preciso de ajuda aqui.

Obrigado

conteúdo do arquivo .service

[Unit]
Description=Apix

[Service]
WorkingDirectory=/apix
ExecStart=/usr/bin/dotnet /APIX/Apix.dll

[Install]
WantedBy=multi-user.target

Quando eu começo o aplicativo eu mesmo, eu posso ver que o udp-port está sendo usado pelo dotnet. Mas quando o serviço executa o aplicativo, esta linha desaparece.

netstat -lntup
udp    0   0 0.0.0.0:14235    0.0.0.0:*     11319/dotnet

    

Answer 1

Livejournal de Dan Walsh de 2014 tem uma descrição de unconfined_service_t , embora seja tão pesado no jargão do SELinux que eu receio que você não consiga aproveitar muito o seu nível atual de conhecimento do SELinux.

De acordo com seus comentários, os rótulos do SELinux para o processo foram:

• quando iniciado com um arquivo .service: system_u:system_r:unconfined_service_t:s0
• quando iniciado manualmente: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Os marcadores do SELinux têm quatro partes:

• Usuário do SELinux (com o sufixo _u )
• Função SELinux (com o sufixo _r )
• Tipo SELinux (com o sufixo _t )
• e uma definição de nível do SELinux, que é usada apenas com uma política SELinux completa (Segurança militar e similares) Segurança em vários níveis , não com a política padrão direcionada .

Na política padrão do SELinux, o identificador de usuário do SELinux é diferente do seu nome de usuário regular: de fato, o SELinux não se importa com quem os arquivos ou processos pertencem, apenas se você é um processo essencial do sistema ou algo iniciado por um ( system_u ), um administrador ( sysadm_u ), um usuário comum ( user_u ) ou algo que tenha sido especificado como irrestrito pela política do SELinux ( unconfined_u ).

A parte da função pode ser usada para especificar várias funções de "administrador parcial", como dbadm_r para administração da base de dados ou logadm_r para acesso a logs do sistema.

A parte mais importante em relação à política SELinux segmentada é a especificação de tipo ou a parte com o sufixo _t .

unconfined_service_t deve ser um tipo irrestrito, então não tenho certeza do que deu errado. Talvez os arquivos sob a árvore de diretórios /APIX/ não estejam marcados e isso possa estar causando os problemas?

Como os processos, os arquivos também devem ter um rótulo do SELinux, visível com ls -Z . Em geral, o SELinux dá um default_t para quaisquer arquivos que não tenham rótulo especificado. Quando confrontado com default_t , o SELinux "pensa": "Eu não sei o que é isso; pode ser Ultra Top Secret que perdeu seu rótulo, então vamos mantê-lo extra seguro até que algum administrador nos diga o rótulo apropriado para isso " Resumindo, default_t é algo que você precisa corrigir.

Os arquivos normalmente herdarão a rotulagem do diretório em que estão no momento da criação, a menos que haja uma regra SELinux especificada que diga o contrário. Mas se você criar um novo diretório de nível superior, como /APIX , precisará decidir como rotulá-lo, ou então você acaba com default_t , o que pode causar problemas.

Você pode tentar definir semanage permissive -a unconfined_service_t : ele permite todos os serviços que usam unconfined_service_t de acesso gratuito, enquanto registra as violações de política do SELinux como /var/log/auth/ , como se o SELinux estivesse totalmente ativado para elas. Em seguida, executar audit2why na parte relevante do log de auditoria deve fornecer uma descrição mais clara do motivo pelo qual o SELinux está impedindo o programa de fazer algo que deseja fazer.

A correção correta pode ser simplesmente rotular o diretório /APIX/ com um rótulo de sistema de arquivos adequado.