Als Consultant begegne ich öfter Konzepten jeglicher Art, sei es das ich sie erstellen darf oder mich bei der Umsetzung an diese halten muss. Besonders wenn letztere unkommentiert als Firmenrichtlinie hinzunehmen sind, komme ich oft nicht mehr aus dem Kopfschütteln raus. In diesem Blogpost will ich nun anfangen mit solchen Konzepten abzurechnen und werde wohl immer wieder neue Themen folgen lassen. Ich werde hierbei keine Kundenbeispiele direkt übernehmen sondern Beispiele mischen um es noch weiter zu überspitzen. Auch soll sich natürlich niemand angegriffen fühlen, wenn sein Konzept ähnlich aussieht, denn meist lässt es sich mit historisch gewachsen begründen. Aber vor allem will ich Probleme aufzeigen, die durch die Konzepte erstehen und dazu anregen solche veralteten Konzepte auf den Prüfstand zu stellen.
Das erste Thema, das ich aufgreifen möchte, ist das Thema Softwareinstallation. Die meisten Projekte und Administratoren haben mittlerweile eingesehen, dass lokale Installation aus dem Quelltext-Archiv nicht mehr zeitgemäß ist. Darum liefern Projekte oftmals auch direkt Pakete aus oder stellen zumindest die dazu nötigen SPEC-Files bereit. Die Gründe hierfür sind meist Nachvollziehbarkeit, geringerer Aufwand, kein Kompiler auf dem System, kein mühsames Ermitteln von Abhängigkeiten, etc. Daher existieren viele Konzepte für das Paketieren von Software, welche nicht vom Distributor ausgeliefert wird. Genau mit diesen möchte ich mich beschäftigen.
Nun auf welche Vorgaben trifft man häufig?
* Selbst paketierte Software soll in ein bestimmtes Verzeichnis installiert werden
* Die Software soll einem speziellen eigenem Benutzer gehören
* Alles soll aus einem einzelnen Paket kommen
* Das Paket soll schon die fertige Konfiguration enthalten
* Pakete müssen parametrierbar sein, da je nach Umgebung andere Pfade, Benutzer, etc. verwendet werden sollen.
Mit diesen Vorgaben möchte ich mich nun im Folgenden auseinandersetzen.
Das Argument selbst paketierte Software in ein eigenes Verzeichnis zu installieren ist üblicherweise Sicherheit. Dieser Mythos hält sich erstaunlicherweise und ich suche den Sicherheitsgewinn ähnlich verzweifelt wie den Yeti oder Nessie. Vielleicht lässt sich hier noch entsprechend argumentieren wenn das Verzeichnis mit speziellen Mount-Optionen als separate Partition eingehängt ist. Aber die Optionen, die einen wirklichen Sicherheitsgewinn bieten wie ACLs oder das Abschalten gewisser Optionen wie das Ausführen von Dateien, Uid-Flags, Devices, werden hier meist nicht genutzt. Zudem könnten diese meist besser und gezielter eingesetzt werden, wenn das Paket in Standardpfaden installiert ist und nur gewisse Verzeichnisse ausgehängt werden, zum Beispiel für temporäre Daten.
Gefährlich wird dies meist in Kombination mit der Vorgabe alles einem bestimmten Benutzer zu übereignen. Eigentlich ist ein Benutzername völlig egal. Benutzer unter denen ein Dienst läuft sollten sich aber üblicherweise nicht am System anmelden können und auch nicht auf schreibend auf ihre Konfiguration oder gar Binärdateien zugreifen können. Die Vorgabe kommt meist daher, dass der Benutzer dann allerdings zur Administration verwendet wird statt administratives und Dienstkonto zu trennen. Kann der Dienst nun seine Konfiguration schreiben, eröffnet dies viele Möglichkeiten für Exploits, denn es hat meist seinen Grund warum ein Dienst mit einem unpriviligierten Benutzer läuft. Noch besser wird es wenn der Benutzer den Dienst mittels sudo als root starten darf und Startskript, in dieses eingebundene Dateien oder Binärdateien verändern kann, damit sind in Sekunden die Rechte ausgeweitet, also genau das Gegenteil vom Ziel der Vorgabe erreicht.
Auch andere Sicherheitskonzepte wie SELinux werden durch die verbogenen Pfade schnell unwirksam, denn ohne die entsprechenden Dateikontexte greift die Policy nicht mehr. Der Aufwand Pakete so umzubiegen und dann weiterzupflegen, insbesondere wenn auch Python-, Perl- oder ähnliche Pfade umgebogen werden, ist dann üblicherweise auch so groß, dass Updates seltener gemacht werden als wenn die Software ohne weiteren Aufwand bezogen werden könnte. Auch dies setzt die Sicherheit weiter herunter.
Natürlich gibt es auch Konzepte, die den Aufwand gering halten, wie die von Red Hat eingeführten Software Collections, trotzdem muss immer noch selbst Aufwand betrieben werden. Der Aufwand ist dann besser darin investiert ein Konzept zu erstellen, welches dem Administrator der Zusatzsoftware erlaubt entsprechende Befehle mit sudo aufzurufen und Konfigurationsdateien über ACLs zu editieren, Logdateien zu lesen, …
Die Vorgaben zusätzliche Dateien oder angepasste Konfigurationen schon mit dem Paket mitzuliefern sind zwar machbar, erhöhen aber die Komplexität weiter und es lässt sich schwerer nachvollziehen woher Dateien ursprünglich kommen. Zusätzliche Dateien sollten also in eigene Pakete, Konfigurationen wenn man nicht auf eine Konfigurationsmanagementlösung setzen möchte in ein eigenes Konfigurationspaket. Über Befehle wie rpm -qf lässt sich dann nachprüfen aus welchem Paket eine Datei kommt, mit rpm -qi erhält man Informationen wie die Bezugsquelle und rpm -qV zeigt welche Dateien nachträglich verändert wurden.
Die Anforderung Pakete parametrierbar zu machen finde ich besonders seltsam, da es beim Paketieren nicht nur darum geht Software nicht auf dem System zu übersetzen, sondern auch Nachvollziehbarkeit in allen Aspekten zu schaffen. Da sich nie ausschließen lässt, dass ein anders gesetzter Parameter die ausgeführte Software beeinflusst, geht hierdurch für mich viel Nachvollziehbarkeit verloren. Diese möchte man besonders beim Updaten haben um Probleme auszuschließen.
Ich hoffe zum Nachdenken angeregt zu haben und Argumentationsgrundlagen für entsprechende Konzepte geliefert zu haben. Die nächsten Konzepte, die ich bei Gelegenheit betrachten möchte, sind das Benutzer- und Softwaremanagement und danach fällt mir bestimmt noch weiteres ein, wenn Interesse besteht. Und wer sein Konzept von mir zerpflückt haben möchte oder eins geschrieben braucht, ich bin natürlich ebenso käuflich wie die Kollegen. 😉
