
Tengo un servicio ubicado en /usr/lib/systemd/system. Este servicio ejecuta la aplicación que he estado desarrollando (.net core 2.0). La misma aplicación se ejecuta en diferentes máquinas (centos7 ambas). Usan sockets udp para encontrarse.
He estado probando esta aplicación durante mucho tiempo antes de prepararme..servicioarchivo para ellos y todo estaba funcionando muy bien. Pudieron transmitirse mensajes entre sí.
Cuando el servicio ejecuta la aplicación, el único mensaje que esa instancia puede recibir es el que esa misma instancia estaba transmitiendo en primer lugar. Misma situación en las otras máquinas. Pueden recibir sus propias transmisiones pero no las del otro.
Como soy nuevo en Linux y no estoy seguro de dónde buscar ni qué debo buscar, encontré información inútil y es por eso que necesito ayuda aquí.
Gracias
Contenido del archivo .service
[Unit]
Description=Apix
[Service]
WorkingDirectory=/apix
ExecStart=/usr/bin/dotnet /APIX/Apix.dll
[Install]
WantedBy=multi-user.target
Cuando inicio la aplicación, puedo ver que dotnet está utilizando el puerto udp. Pero cuando el servicio ejecuta la aplicación, esta línea desaparece.
netstat -lntup
udp 0 0 0.0.0.0:14235 0.0.0.0:* 11319/dotnet
Respuesta1
Livejournal de Dan Walsh de 2014tiene una descripción de unconfined_service_t
, aunque tiene tanta jerga de SELinux que me temo que es posible que no le aproveches mucho con tu nivel actual de conocimiento de SELinux.
Según sus comentarios, las etiquetas SELinux para el proceso fueron:
- cuando se inicia con un archivo .service:
system_u:system_r:unconfined_service_t:s0
- cuando se inicia manualmente:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Las etiquetas SELinux tienen cuatro partes:
- Usuario SELinux (con el
_u
sufijo) - Rol SELinux (con el
_r
sufijo) - Tipo SELinux (con el
_t
sufijo) - y una definición de nivel SELinux, que sólo se utiliza con un completoSeguridad multinivelPolítica SELinux (seguridad militar y similares), no con la predeterminadadirigidopolítica.
En la política predeterminada de SELinux, el identificador de usuario de SELinux es distinto de su nombre de usuario habitual: de hecho, a SELinux no le importa exactamente a quién pertenecen los archivos o procesos, solo si usted es un proceso esencial del sistema o algo iniciado por uno ( system_u
) , un administrador ( sysadm_u
), un usuario normal ( user_u
) o algo que haya sido especificado como no restringido por la política SELinux ( unconfined_u
).
La parte de rol se puede utilizar para especificar varios roles de "administrador parcial", como dbadm_r
para la administración de bases de datos o logadm_r
para acceder a los registros del sistema.
La parte más importante respecto a ladirigidoLa política de SELinux es la especificación de tipo o la parte con el _t
sufijo.
unconfined_service_t
debería ser un tipo sin restricciones, por lo que no estoy seguro de qué sale mal allí. ¿Quizás todos los archivos del /APIX/
árbol de directorios no están etiquetados y eso podría estar causando los problemas?
Al igual que los procesos, los archivos también deben tener una etiqueta SELinux, visible con ls -Z
. En general, SELinux proporciona un default_t
para cualquier archivo que no tenga una etiqueta especificada. Cuando se enfrenta a default_t
, SELinux "piensa": "No sé qué es esto; podría ser Ultra Top Secret el que ha perdido su etiqueta, así que mantengámoslo extra seguro hasta que algún administrador nos diga cuál es la etiqueta adecuada". En resumen, default_t
es algo que deberás arreglar.
Los archivos normalmente heredarán el etiquetado del directorio en el que se encuentran en el momento de la creación, a menos que se especifique una regla SELinux que diga lo contrario. Pero si crea un nuevo directorio de nivel superior como /APIX
, necesitará decidir cómo etiquetarlo, o terminará con default_t
, lo que puede causar problemas.
Puede intentar configurar semanage permissive -a unconfined_service_t
: permite que cualquier servicio use unconfined_service_t
acceso gratuito, mientras aún registra cualquier violación de la política de SELinux como /var/log/auth/
si SELinux estuviera completamente habilitado para ellos. Luego, ejecutar audit2why
la parte relevante del registro de auditoría debería brindarle una descripción más clara de por qué SELinux está bloqueando que el programa haga algo que quiere hacer.
La solución correcta podría ser simplemente etiquetar el /APIX/
directorio con una etiqueta de sistema de archivos adecuada.