TokkNet

YaST2 Angeblich Ohne Root Rechte

trotz ausführung als User root

Von Zeit zu Zeit habe ich das zweifelhafte Vergnügen, mit SLES-Systemen arbeiten zu dürfen. Dabei muss natürlich auch mit yast bzw. yast2 interagiert werden, um das System und einige Dienste zu konfigurieren. Von der Philosophie, die eigentlichen Konfigurationsdateien hinter einer GUI zu verstecken kann man halten was man will, ich halte davon nichts - aber das nur am Rande.

Bei meinem letzten Ausflug in die Welt dieser Enterprise Distribution ist mir dann ein kurioser Fehler aufgefallen. Ich habe mich in das System eingeloggt, meinen Benutzerkontext auf root geändert und YaST2 gestartet. Dabei wurde ich von folgender Meldung begrüßt:

YaST2 Control Center is not running as root.
You will only see modules which do not require root privileges.

Mit meiner Anmeldung war aber alles in Ordnung, wie ein kurzer Check ergab:

$# whoami
root

Nach einigem Googeln fand ich dann mehrere Threads, die mit dem gleichen Problem zu kämpfen hatten. Anscheinend tritt die Fehlermeldung relativ häufig und bei einer Vielzahl von Problemen auf. Es könnte daran liegen, dass zu wenig RAM zur Verfügung steht - aber das war bei mir nicht das Problem.
In einem anderen Thread hatte ein Benutzer ebenfalls das obige Problem, hier lag es an einem fehlenden Logverzeichnis /var/log/YaST2.
Bei mir war das Verzeichnis zwar vorhanden, aber der Thread brachte mich auf die richtige Spur - offensichtlich tritt der Fehler auf, wenn YaST2 keine Logdateien schreiben kann. Ein Check mit df -h ergab eine Festplattenauslastung von 100% - damit konnten natürlich auch keine Dateien geschrieben werden. Nach einer Bereinigung der Festplatte konnte YaST2 wieder normal ausgeführt werden.
Ob es in diesem speziellen Fall daran liegt, dass keine Logfiles geschrieben werden konnten oder ob eine volle Festplatte auch andere Probleme mit sich bringt, kann ich natürlich nicht mit Sicherheit sagen, da keine Logfiles geschrieben wurden.

Zusammenfassend kann man sagen, dass die obige Meldung relativ generisch zu sein scheint und nicht unbedingt auf fehlende Rechte hinweist.

Passwortlogin über SSH unter Ubuntu deaktivieren

Oder: Warum Sicherheitseinstellungen immer getestet werden müssen

Eine der ersten Dinge, die ich bei einem neuen Server immer anpasse ist die sshd_config, der Login über SSH mittels Passwort wird deaktiviert:

PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM no

Normalerweise geht man davon aus, das die Einträge funktionieren. Meist testet man den Login dann vom eigenen PC aus und stellt zufrieden die Verwendung des Zertifikates fest.

Cloud Init

Natürlich wird Ubuntu aber heutzutage mit Cloud-Init ausgeliefert und seit Ubuntu 20.04 bringt dies direkt eine neue Config-Datei namens /etc/ssh/sshd_config.d/50-cloud-init.conf mit, die eine einzige Zeile enthält:

PasswordAuthentication yes

Da das Einbinden des Verzeichnisses sshd_config.d sehr weit oben in der sshd_config stattfindet, ist dies fast immer das erste Vorkommen der PasswordAuthentication Direktive. Das bedeutet, dass der hier angegebene Wert erhalten bleibt und die Passwortauthentifizierung trotz aller anderen Einstellungen aktiviert bleibt.
Um die Möglichkeit, sich mit einem Passwort anzumelden, vollständig zu deaktivieren, muss diese Datei daher gelöscht oder bearbeitet werden. Da diese Datei jedoch nur einem Zweck dient, kann sie mit gutem Gewissen gelöscht werden.

Abschließende Bemerkungen

1. Dieser Sachverhalt zeigt deutlich, dass Sicherheitseinstellungen immer getestet werden müssen, egal wie sorgfältig man die Konfiguration durchführt, und zwar auch aus der Sicht eines externen Kontextes, in diesem Fall die Anmeldung ohne eigenes Zertifikat zu erzwingen.
2. WTF Canonical?

Unpriviligertes Binding an priviligierte Ports

Ports unter 1024 an User-Prozesse binden

Normalerweise erlaubt es der Linux-Kernel nicht, dass sich unprivilegierte Prozesse an Ports unter 1024 binden. Daher laufen die meisten (Web-) Server-Prozesse als root. Sicherheitstechnisch ist es natürlich nicht ideal, das gerade die Prozesse, welche sich um die Bearbeitung von Anfragen aus dem Internet kümmern umfassende Rechte haben, da dies im Falle einer feindlichen Übernahme des Prozesses natürlich auch direkt zu Root-Rechten auf dem ganzen Systems führt.
An dieser Stelle bietet Systemd jedoch die Möglichkeit, unserem Service die Bindung an die Ports zu erlauben, in dem man dem entsprechenden Prozess per AmbientCapabilities =CAP_NET_BIND_SERVICE die Berechtigung erteilt, sich an die Ports unter 1024 zu binden. Eine Übersicht über alle anderen erteilbaren Berechtigungen gibt es zum Beispiel in der Linux Man Page zu den Capabilities.

Bei der Gelegenheit kann man direkt noch per CapabilityBoundingSet=CAP_NET_BIND_SERVICE einschränken, das der Service nur diese Berechtigung bekommen darf und keine anderweitigen bekommen kann Die Unit-Datei sollte dann so aussehen:

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

Am besten kann man solche Änderungen als Drop-In in einer eigenen Override-Datei anlegen.

Unerreichbare Resourcen unmounten

ohne reboot

Wenn Netzwerkresourcen plötzlich nicht mehr erreichbar sind oder USB-Platten ausfallen kann es vorkommen, das Linux diese noch als gemounted aufführt, jeglicher Versuch in den Verzeichnissen zu arbeiten führt jedoch zu einem hängen des Prozesses.
Auch das aushängen der entsprechenden Ordner klappt in diesem Fall oft nicht mehr, da der Kernel im Hintergrund noch versucht schreibvorgänge zu Ende zu bringen und Resourcen zu schließen.

in so einem Fall können die Optionen -l oder -f helfen.

umount -l, verfügbar ab Kernel 2.4.11, hängt das Laufwerk aus und versucht dann im Hintergrund alle Resourcen aufzuräumen.
umount -f - wie bei den meisten anderen befehlen bedeutet -f force und bewirkt das sofortige aushängen ohne Rücksicht auf Konsequenzen.

Nicht reagierendes System neu starten

Sogar wenn kein Dateisystem unter / verfügbar ist

Ab und an kann es passieren, dass ein System sich nicht mehr beenden lässt. Sei es, weil der Kernel versucht Hintergrundaufgaben abzuschließen oder kein Dateisystem mehr vorhanden ist (z.B. durch ein (meist versehentliches) erzwungenes unmounten von /) und somit die Executables für systemctl, reboot etc. einfach fehlen.
Sitzt man direkt am Rechner hilft natürlich der Ein-/Ausschalter aber oft ist die Sache ja nicht so einfach.

Mit vorhandenem Dateisystem

Wenn noch ein Dateisystem eingebunden ist, kann der Befehl reboot verwendet werden, mit einem der drei folgenden Möglichkeiten:

• reboot -f: Killt alle Prozesse, unmounted Dateisysteme (oder hängt sie nur lesbar ein), startet dann neu
• reboot -ff: Startet das System sofort neu, ohne Prozesse vorher zu beenden oder Dateisysteme zu unmounten
• reboot -n: Führt keine Syncronisation der eingebundenen Dateisysteme durch.

Die ersten beiden Befehle können auch durch systemctl --force bzw. systemctl --force --force ersetzt werden, wenn der Befehl reboot nicht verfügbar ist.

Ohne vorhandes Dateisystem

Ohne Dateisystem gibt es die Möglichkeit, einen SystemRequest abzusetzen, der das System direkt und ohne Ausführung irgendwelcher Anwendungen neu startet.

echo "128 " >/proc/sys/kernel/sysrq #Den folgenden Request erlauben
echo b > /proc/sysrq-trigger        #Reboot