Warum das Verschieben eines VPN-Zertifikats sein SELinux-Label bricht

Zertifikate können im richtigen Verzeichnis liegen, mit lesbarem Modus und Root-Besitz, und der Dienst kann trotzdem melden, dass er die Datei nicht öffnen kann. Auf einem SELinux-System deutet diese Kombination auf einen bestimmten Mechanismus hin und nicht auf Berechtigungen. Das Label reiste mit der Datei, weil ein Umbenennen kein neues Objekt erzeugt. Der Inode behielt den Sicherheitskontext, den er am alten Pfad hatte, und die Policy für den neuen Pfad kam nie dazu, ihren eigenen zuzuweisen.

Was ein Umbenennen tatsächlich mit einem Label macht

Eine Datei trägt ihren SELinux-Kontext als Attributdaten, die am Inode hängen. Ein Umbenennen innerhalb eines Dateisystems ändert den Verzeichniseintrag und sonst nichts, was schnell und atomar ist und der Grund dafür, dass der Kontext den Umzug übersteht. Keine Policy wird befragt, kein Standardwert angewandt und keine Warnung ausgegeben.

Kopieren verhält sich anders. Eine Kopie erzeugt einen neuen Inode im Zielverzeichnis, und die Policy weist einen Kontext nach dem Typ dieses Verzeichnisses zu, sodass ein kopiertes Zertifikat meist korrekt beschriftet wird, während ein verschobenes falsch bleibt. Genau dieser eine Unterschied erklärt den größten Teil der Verwirrung in dieser Art von Ticket.

Verschiebungen zwischen Dateisystemen fallen auf Kopiersemantik zurück, sodass sich derselbe Befehl auf zwei Rechnern unterschiedlich verhalten kann, je nachdem, ob /etc auf einem eigenen Volume liegt. Prüfen Sie das, bevor Sie schließen, das Werkzeug sei unzuverlässig. Ein Blick auf die Mount-Tabelle sagt Ihnen, welche Art von Verschiebung Sie ausgeführt haben.

Lesen Sie das aktuelle Label gegen das erwartete

Drei reine Lesebefehle beantworten die Frage, ohne etwas zu ändern. Der erste zeigt, was die Datei jetzt hat, der zweite meldet, was die Policy für genau diesen Pfad erwartet, und der dritte listet jede Datei unter dem Verzeichnis, deren Label abweicht.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Dem Probelauf ist zu trauen, denn er benennt jede Datei, deren Kontext von der Policy abweicht, und lässt das System dennoch unangetastet. Erscheint das Zertifikat in dieser Liste, haben Sie die Diskrepanz gefunden zwischen dem, was der Pfad bedeutet, und dem, was die Datei behauptet. Erscheint es nicht, ist das Label bereits das, was die Policy will, und Ihre Zeit gehört woanders hin.

Korrelieren Sie den Unterschied dann mit einer tatsächlichen Verweigerung. Eine Abweichung ist ein Beleg für ein falsches Label, kein Beweis dafür, dass der Dienst deswegen versagt hat, und eine Korrektur ohne entsprechende Verweigerung im Protokoll ist eine Vermutung mit zusätzlichen Schritten.

Stellen Sie die Zuordnung wieder her, statt eine Ausnahme zu erfinden

Für einen Standardort bildet die Policy den Pfad bereits ab, also wendet restorecon sie an, und die Arbeit ist getan. Halten Sie den Umfang auf das Verzeichnis beschränkt, das Sie reparieren; das ganze Dateisystem neu zu beschriften ist langsam, störend und begräbt den ursprünglichen Fehler unter einer sehr großen Änderung.

Bei einem eigenen Verzeichnis zählt die Reihenfolge, und sie umzukehren ergibt einen Befehl, der Erfolg meldet, während sich nichts ändert. Die Zuordnung gehört in die Policy, das Neubeschriften gehört ans Ende, und der Probelauf gehört vor beides. Diesen letzten Teil zu überspringen ist der Weg, auf dem ein Pfad, der nie falsch war, trotzdem neu beschriftet wird.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon wendet eine Zuordnung an; erfinden kann es keine. Wenn keine Regel den Pfad beschreibt, gibt es nichts wiederherzustellen, und deshalb muss die dauerhafte Zuordnung vor dem Neubeschriften existieren. Notieren Sie, welche Konfiguration diese Zuordnung besitzt, denn sonst erzeugt ein späterer Umzug, ein Paket-Update oder ein Neubeschriften den Fehler erneut, und die nächste Person beginnt bei null.

Warum chcon nicht die Lösung ist

chcon schreibt einen Kontext direkt auf die Datei. Es wirkt sofort und ist die am wenigsten dauerhafte verfügbare Option, denn ein Neubeschriften des Dateisystems wendet die Policy erneut an und verwirft manuelle Änderungen, ohne zu fragen. Die Datei sieht repariert aus, und die Reparatur hat ein Ablaufdatum, das niemand aufgeschrieben hat. Was Sie stattdessen wollen, ist eine Regel, die den Pfad beschreibt, damit jede Datei, die dort ankommt, automatisch dieselbe Behandlung erhält.

Schlimmer noch, es lehrt die falsche Lektion: die zugrunde liegende Zuordnung fehlt weiterhin, also kehrt der Fehler Wochen später ohne offensichtlichen Auslöser und ohne Erinnerung an den Workaround zurück. Verwenden Sie chcon nur als vorübergehendes Experiment zur Bestätigung einer Hypothese, ersetzen Sie es dann durch eine Zuordnung, die das nächste Neubeschriften übersteht, und prüfen Sie, ob der Ersatz tatsächlich vorhanden ist.

Wenn das Label richtig ist und der Zugriff trotzdem scheitert

Beginnen Sie bei den übergeordneten Verzeichnissen. Die Durchquerungsberechtigung wird auf jeder Komponente des Pfads geprüft, daher bleibt ein korrekt beschriftetes Zertifikat in einem Verzeichnis, in das der Dienst nicht gelangen kann, weiterhin unlesbar. SELinux und die gewöhnliche Berechtigung müssen jeden Schritt erlauben, und das eine zu reparieren repariert das andere nicht.

Prüfen Sie dann die Prozessidentität und die eigene Sandbox des Dienstes. Eine Unit mit restriktiver Sandbox kann den Zugriff auf eine Datei verweigern, die die Policy bereitwillig erlauben würde, und aus der Protokollzeile sehen beide Ursachen gleich aus. Bestätigen Sie, welcher Prozess tatsächlich fragt, nicht welcher Ihrer Annahme nach fragt.

Denken Sie daran, dass dontaudit-Regeln Verweigerungsmeldungen unterdrücken können, sodass ein leeres Audit-Protokoll ein schwacher Beleg statt eines Beweises ist. Wenn die Policy richtig aussieht und der Zugriff trotzdem scheitert, untersuchen Sie, bevor Sie ein breites Allow-Modul erzeugen, und deaktivieren Sie SELinux nicht, um das Symptom verschwinden zu lassen. Beide Abkürzungen ergeben ein System, das zu funktionieren scheint, und eine Sicherheitslage, die niemand beschreiben kann. Eine kurze Untersuchung ist besser als beides.