Seite wählen

Minimale Rechte und persönliche Accounts zur Administration

von | Jul 8, 2016 | Security, Linux, Icinga

Icinga 2
Nachdem in unserer letzten „Icinga 2“-Schulung die Diskussion aufkam wie man Icinga 2 am besten mit minimalen Rechten konfiguriert und administriert, will ich mich dieser Thematik mal annehmen. Dies wird zwar anhand des Beispiels Icinga 2 auf CentOS 7 sein, aber lässt sich so auf jeden Dienst anwenden, der in Konfigurationsdateien verwaltet wird.
Ausgangsbasis
Die Ausgangsbasis stellen immer die Rechte dar, die durch das Package bei der Installation vorgegeben werden. Diese sollen unverändert bleiben, da sie sonst bei einem Update wieder auf den Standard des Packages zurückgesetzt werden. Als zweites gehen wir mal davon aus, dass eine Anmeldung als unpriviligierter Benutzer mit einem persönlichen Account möglich ist, wobei egal ist ob dieser lokal angelegt ist oder aus einem zentralen Verzeichnisdienst kommt, und dass dieser zur Administration genutzt werden soll.
Bei Icinga 2 sehen die Rechte nach der Installation folgendermaßen aus:

  • Auf dem Hauptverzeichnis /etc/icinga2 hat root alle Rechte, die Gruppe icinga darf lesen und browsen, alle anderen haben keine Rechte.
  • Auf die Dateien und Unterverzeichnisse hat der Benutzer icinga alle Rechte, die Gruppe icinga darf lesen und Verzeichnisse browsen, alle anderen haben keine Rechte.
  • Die Ausnahme bildet die Datei /etc/icinga2/init.conf, bei der die Benutzerrechte auf root liegen, aber auch nicht editiert werden sollte.

Zusätzlich zu den Dateirechten brauchen wir zur Administration Befehle wie systemctl reload icinga2.service um Icinga 2 neuzustarten oder auch icinga2 daemon -C zum Validieren der Konfiguration. Die Systemkommandos können nur als root ausgeführt werden, die Icinga-Kommandos als root oder icinga. Der Benutzer icinga ist allerdings als Benutzer gedacht unter dem der Dienst läuft und hat daher keine Benutzerumgebung, Kommandos können mit sudo aber trotzdem mit seinen Rechten ausgeführt werden.
Ein unpriviligierter Account kann nun noch nicht mal die Konfiguration lesen oder auch nur durch die Verzeichnisse navigieren, den Dienst nicht steuern oder Icinga-Kommandos absetzen. Dies können wir auf zwei Arten lösen. Methode 1 sind Gruppenrechte, Methode 2 ACLs, beides angereichert um eine Prise sudo um Kommandos unter anderen Rechten auszuführen.

Methode 1: Gruppenrechte
Um unsere Aufgabenstellung mit Gruppenrechten zu lösen, müssen wir nun folgendes tun. Zu erst nehmen wir den Benutzer in die Gruppe icinga auf, dies erlaubt ihm die Konfiguration zu lesen und durch die Verzeichnisse zu navigieren. Damit darf er allerdings die Basiskonfiguration nicht editieren, dies kann so gewünscht sein damit der Benutzer nur Monitoringobjekte pflegt oder es erfordert zusätzliche Berechtigungen über sudo. Hierbei reichen Rechte auf den Benutzer icinga und das Kommando sudoedit! root ist nicht notwendig. sudoedit erlaubt es im Gegensatz zu vi nicht externe Kommandos unter den erhöhten Rechten aufzurufen. Zur Konfiguration der Monitoringobjekte sollte eh die Beispielkonfiguration unter conf.d durch ein eigenes Verzeichnis ersetzt werden, welches dann neben allen Rechten für die Gruppe noch das Setgid-Bit erhält um die Gruppenzugehörigkeit zu erzwingen. Gleichen gilt wenn man den Konfigurationssynchronisationsmechnismus von Icinga 2 nutzt für die Verzeichnisse unterhalb von zones.d. Für die Systemkommandos dann noch zusätzliche Rechte diese als root auszuführen und die Icinga-Kommandos als icinga für die Gruppe icinga.
Der Ansatz mit Gruppenrechten hat den Nachteil man muss wissen welche Dateien die Basiskonfiguration darstellen und welche zusätzliche Monitoringobjekte, daher würde ich persönlich ACLs bevorzugen, aber diese gelten manchen Admins und Unternehmen als Teufelszeug. Oftmals weil diese beim gewohnten Blick mit ls -l nur an einem + zu erkennen sind.
Methode 2: ACLs
Die Umsetzung mit ACLs sieht folgendermaßen aus. Auch hier würde ich prinzipiell alle Admins in eine Gruppe aufnehmen, diese kann aber eine völlig beliebige sein wie beispielsweise icingaadmins. Dieser Gruppe werden dann mittels ACLs Rechte rekursiv auf /etc/icinga2 gewehrt, zusätzlich werden diese als Default festgelegt. Für die Monitoringobjekte wird wie oben beschrieben ein eigenes Verzeichnis angelegt welches die Gruppe icingaadmins erzwingt, damit auch sicher der Dienstbenutzer icinga diese lesen kann geben wir diesem auch über Default-ACLs lesenden Zugriff auf die Verzeichnisse (oder auch direkt ab dem Hauptverzeichnis). Die Kommandos erlauben wir wieder mit sudo allerdings diesmal für unsere Admingruppe icingaadmins.
Der Ansatz mit ACLs ist also komfortabler für den Admin, da er nicht wissen muss welche Datei er mit erhöhten Rechten editieren muss. Sicherer ist die Lösung auch da nicht die Gruppe des Dienstbenutzers mehr Rechte bekommen kann und flexibler da das Prinzip auch auf mehrere Benutzergruppen angewendet werden kann um beispielsweise System- und Netzwerkadmins unterschiedliche Dateien verwalten zu lassen.
Mit beiden Ansätzen lässt sich also eine Administration mit minimalen Rechten und persönlichen Accounts ermöglichen, welche nur bei Bedarf über sudo ausgeweitet werden können. Wem dies noch nicht sicher genug ist kann sich noch SELinux anschauen, denn die „Icinga 2“-Policy bringt hier eine SELinux-Rolle mit, die auch über den SELinux-Context den Benutzer rein auf die „Icinga 2“-Administration beschränkt.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Security | Linux | Icinga