systemd-Dienst - UDP-Broadcast kann andere Maschine nicht erreichen

systemd-Dienst - UDP-Broadcast kann andere Maschine nicht erreichen

Ich habe einen Dienst unter /usr/lib/systemd/system. Dieser Dienst führt die App aus, die ich entwickelt habe (.net core 2.0). Dieselbe App läuft auf verschiedenen Maschinen (beide CentOS7). Sie verwenden UDP-Sockets, um sich gegenseitig zu finden.

Ich habe diese App sehr lange getestet, bevor ich sie vorbereitet habe.ServiceDatei für sie und alles funktionierte wunderbar. Sie konnten Nachrichten aneinander senden.

Wenn der Dienst die Anwendung ausführt, kann diese Instanz nur die Nachricht empfangen, die sie ursprünglich gesendet hat. Auf den anderen Maschinen ist die Situation gleich. Sie können ihre eigenen Sendungen empfangen, aber nicht die der anderen.

Da ich neu bei Linux bin und nicht sicher bin, wo ich suchen soll und wonach ich suchen soll, bin ich auf einige nutzlose Informationen gestoßen und deshalb brauche ich hier etwas Hilfe.

Danke


Inhalt der Servicedatei

[Unit]
Description=Apix

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

[Install]
WantedBy=multi-user.target

Wenn ich die App selbst starte, kann ich sehen, dass der UDP-Port von dotnet verwendet wird. Aber wenn der Dienst die App ausführt, verschwindet diese Zeile.

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

Antwort1

Dan Walshs Livejournal von 2014enthält eine Beschreibung von unconfined_service_t, die allerdings so sehr mit SELinux-Jargon gefüllt ist, dass ich befürchte, dass Sie mit Ihrem derzeitigen SELinux-Wissensniveau nicht viel daraus lernen können.

Ihren Kommentaren zufolge waren die SELinux-Bezeichnungen für den Prozess:

  • beim Start mit einer .service-Datei:system_u:system_r:unconfined_service_t:s0
  • beim manuellen Start:unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

SELinux-Labels bestehen aus vier Teilen:

  • SELinux-Benutzer (mit _uSuffix)
  • SELinux-Rolle (mit dem _rSuffix)
  • SELinux-Typ (mit _tSuffix)
  • und eine SELinux-Level-Definition, die nur mit einem vollständigenMehrstufige SicherheitSELinux-Richtlinie (militärische Sicherheit und dergleichen), nicht mit der StandardeinstellunggezieltPolitik.

In der SELinux-Standardrichtlinie unterscheidet sich die SELinux-Benutzerkennung von Ihrem normalen Benutzernamen: Tatsächlich ist es SELinux egal, wem genau Dateien oder Prozesse gehören, sondern nur, ob Sie ein wesentlicher Systemprozess sind oder etwas, das von einem solchen gestartet wurde ( system_u), ein Administrator ( sysadm_u), ein normaler Benutzer ( user_u) oder etwas, das in der SELinux-Richtlinie als uneingeschränkt angegeben wurde ( unconfined_u).

Der Rollenteil kann verwendet werden, um verschiedene „Teiladministrator“-Rollen anzugeben, beispielsweise dbadm_rfür die Datenbankverwaltung oder logadm_rfür den Zugriff auf Systemprotokolle.

Der wichtigste Teil über diegezieltDie SELinux-Richtlinie ist die Typspezifikation oder der Teil mit dem _tSuffix.

unconfined_service_tsollte ein uneingeschränkter Typ sein, daher bin ich mir nicht sicher, was da schief läuft. Vielleicht /APIX/sind die Dateien im Verzeichnisbaum alle unbeschriftet und das könnte die Probleme verursachen?

Wie Prozesse sollten auch Dateien ein SELinux-Label haben, das mit angezeigt werden kann ls -Z. Im Allgemeinen vergibt SELinux ein default_tfür alle Dateien, für die kein Label angegeben ist. Bei denkt default_tSELinux: „Ich weiß nicht, was das ist. Es könnte sich um Ultra Top Secret handeln, das sein Label verloren hat. Also lasst es uns besonders sicher aufbewahren, bis uns ein Administrator das richtige Label dafür nennt.“ Kurz gesagt, default_tist etwas, das Sie beheben müssen.

Dateien übernehmen normalerweise die Bezeichnung des Verzeichnisses, in dem sie sich zum Zeitpunkt ihrer Erstellung befinden, es sei denn, es ist eine SELinux-Regel angegeben, die etwas anderes besagt. Wenn Sie jedoch ein neues Verzeichnis der obersten Ebene wie erstellen /APIX, müssen Sie entscheiden, wie es benannt werden soll, sonst erhalten Sie am Ende default_t, was zu Problemen führen kann.

Sie können versuchen, Folgendes einzustellen semanage permissive -a unconfined_service_t: Dadurch wird allen Diensten der unconfined_service_tfreie Zugriff gestattet, während alle Verstöße gegen die SELinux-Richtlinien weiterhin so protokolliert werden, /var/log/auth/als ob SELinux für sie vollständig aktiviert wäre. Wenn Sie dann audit2whyden entsprechenden Teil des Prüfprotokolls ausführen, sollten Sie eine klarere Beschreibung erhalten, warum SELinux das Programm daran hindert, etwas zu tun, was es tun möchte.

Die richtige Lösung könnte darin bestehen, das /APIX/Verzeichnis einfach mit einer geeigneten Dateisystembezeichnung zu kennzeichnen.

verwandte Informationen