
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
_u
Suffix) - SELinux-Rolle (mit dem
_r
Suffix) - SELinux-Typ (mit
_t
Suffix) - 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_r
für die Datenbankverwaltung oder logadm_r
für den Zugriff auf Systemprotokolle.
Der wichtigste Teil über diegezieltDie SELinux-Richtlinie ist die Typspezifikation oder der Teil mit dem _t
Suffix.
unconfined_service_t
sollte 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_t
für alle Dateien, für die kein Label angegeben ist. Bei denkt default_t
SELinux: „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_t
ist 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_t
freie 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 audit2why
den 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.