Minimale Rechte und persönliche Accounts zur Administration

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.
(mehr …)

Dirk Götz
Dirk Götz
Senior 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.

Weekly Snap: LConf & ACL, OSMC & OSBC Call for Papers

weekly snap5 – 9 May packed in tips for LConf, spreadsheets and streaming clients, three events and Puppet webinar too.
On events, Eva announced our Call for Papers for the Open Source Monitoring Conference and the Open Source Backup Conference, while Bernd headed off to Linux Tag in Berlin.
Christian continued, with a webinar on Puppet and Foreman as Dirk set up restricted user accounts in LConf using ACL.
Finally, Thilo made spread sheet magic with the help of the Ruby Gem, Roo and Marius compared Chromecast, Apple TV and Roku Stick.

Dateisystem-ACLs unter Linux

Neben den bei Linux-Admins allseits bekannten Permission-Bits (Read-, Write- und Execute-Berechtigungen für User, Gruppen bzw. World) gibt es noch weitere Möglichkeiten, die Berechtigungen von Dateien zu definieren. Eine davon ist die Verwendung von Access Control Lists, kurz ACLs.
Mit ACLs kann im Gegensatz zu traditionellen Unix-Berechtigungen für mehrere Benutzer und Gruppen definiert werden, wer Zugriff auf eine Datei erhalten soll. Um ACLs verwenden zu können, muss man ein Dateisystem verwenden, das diese unterstützt (z.B. ext3). Zusätzlich muss das Dateisystem mit der Option “acl” gemountet werden, wie folgendes fstab-Beispiel zeigt:

/dev/sda1     /           ext4    errors=remount-ro,acl	    0       1

Je nach verwendetem Dateisystem ist die “acl”-Option eventuell bereits standardmäßig aktiviert.
Zusätzlich müssen noch Tools installiert werden, um ACLs anzeigen und bearbeiten zu können. Bei Debian sind diese z.B. im Paket “acl” enthalten:

$ sudo aptitude install acl
The following NEW packages will be installed:
  acl
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/70,8 kB of archives. After unpacking 264 kB will be used.
Selecting previously unselected package acl.
(Reading database ... 104211 files and directories currently installed.)
Unpacking acl (from .../acl_2.2.51-8_amd64.deb) ...
Processing triggers for man-db ...
Setting up acl (2.2.51-8) ...

Danach können wir auch schon damit anfangen, ACLs zu verwenden. Zunächst legen wir ein Verzeichnis und eine Test-Datei an, die in den folgenden Beispielen verwendet werden:

$ mkdir acl
$ touch acl/test

Mit Hilfe des Tools “getfacl” können wir uns die ACLs eines Verzeichnisses bzw. einer Datei anzeigen lassen:

$ getfacl acl
# file: acl
# owner: gunnar
# group: gunnar
user::rwx
group::rwx
other::r-x

Obwohl wir noch gar keine ACLs definiert haben, hat das Verzeichnis bereits 3 Einträge. Diese entsprechen den UNIX-Berechtigungen, die z.B. auch von “ls -l” angezeigt werden.
Mit folgenden Befehlen können wir nun die Berechtigungen so anpassen, dass der Benutzer “gunnar” lesend und schreibend auf das Verzeichnis zugreifen kann, während der Benutzer “www-data” nur-lesenden Zugriff hat:

$ chmod 700 acl
$ setfacl -m user:www-data:rx acl

Wenn wir uns das Verzeichnis danach mit ls anzeigen lassen, erkennen wir an dem “+” bei den Berechtigungs-Bits, dass für dieses Verzeichnis ACLs definiert wurde:

$ ls -l
total 52
drwxr-x---+ 2 gunnar gunnar  4096 Mär 21 12:21 acl

Die ACLs können wir uns dann mit getfacl anzeigen lassen:

$ getfacl acl
# file: acl
# owner: gunnar
# group: gunnar
user::rwx
user:www-data:r-x
group::---
mask::r-x
other::---

ACLs von Verzeichnissen werden dabei nicht standardmäßig an Unterverzeichnisse oder Dateien vererbt. Hierzu können wir uns die Berechtigungen von “acl/test” anzeigen lassen:

$ getfacl acl/test
# file: acl/test
# owner: gunnar
# group: gunnar
user::rw-
group::rw-
other::r--

Falls wir Berechtigungen vererben wollen, z.B. damit der “www-data”-Benutzer rekursiv auf alle Dateien in einem Verzeichnis zugreifen kann, müssen wir für das Verzeichnis eine sogenannte Default-ACL definieren. Hierzu gibt es beim Befehl setfacl den Parameter “-d”:

$ setfacl -d -m user:www-data:rx acl

Die Default-ACL gilt dabei ausschließlich für neu-angelegte Unterverzeichnisse und Dateien:

$ touch acl/test2
$ getfacl acl/test2
# file: acl/test2
# owner: gunnar
# group: gunnar
user::rw-
user:www-data:r-x		#effective:r--
group::---
mask::r--
other::---

Weiterführende Informationen zu Unix-ACLs gibt es in den Manpages der Befehle getfacl und setfacl bzw. in acl(5). Neben ACLs gibt es auch noch weitere Möglichkeiten, Berechtigungen zu vergeben, wie beispielsweise SELinux-Labels oder in neueren Versionen des Linux-Kernels NFSv4 ACLs (“Richacls“).

Weekly Snap: OpenLDAP with ACL, NodeJS & Dev Tools Galore

23 – 27 January was filled with developer tools, in particular NodeJS as well as OpenLDAP, with a sys admin email tip to boot.
Martin offered a quick troubleshoot for the Mac error “Index Out Of Range Exception” that popped up as he installed SP2 on the company Exchange 2010.
Then in a development tag team, Angsar briefly reviewed the top tools for software developers with a good dose of scepticism, while Eric went into more depth on one of the better ones – NodeJS. With a quick guide to installation creating a simple .png, he gave the server side Java Script framework the thumbs up.
Finishing off the week, Philipp continued on his OpenLDAP roll, this time in working with ACL on 2.4.x versions.

OpenLDAP 2.4.x und die ACL

In vergangenen Blogposts habe ich erwähnt welche Möglichkeiten OpenLDAP 2.4.x bei der Replikation bietet und wie man neuerdings weitere Schema zu OpenLDAP hinzufügen kann.
Mit dem dynamischen Backend cn=config hat sich auch das bearbeiten der ACL (Access Control List) verändert.
Unter OpenLDAP < 2.4.x war die slapd.conf die richtige Anlaufstelle um Benutzern, Gruppen etc. den Zugriff auf bestimmte Attribute, Objekte, Teilbäume... zu ermöglichen. cn=config als dynamisches Backend fordert hier eine neue Vorgehensweise um die ACL zu administrieren.
Generell gibt es zwei Möglichkeiten neue Zugriffsrechte zu definieren oder bestehende zu ändern.

  • Änderungen direkt in das entsprechende Backend-LDIF eintragen (olcDatabase={1}hdb oder olcDatabase={1}bdb).
  • Änderungen über ein separates LDIF File mit ldapadd oder ldapmodify zu importieren.

Wie bei allen Dingen die im Backend geändert werden gilt auch hier, alle Änderungen werden während der Laufzeit übernommen und erfordern keinen Reload des OpenLDAP Daemons.
Nun aber ans Eingemachte…
Bevor wir eine Access Control List aufbauen können, müssen wir wissen wie die Definition auszusehen hat und welche Möglichkeiten der Definition es gibt.
Die Definition einer ACL hat sich zu älteren OpenLDAP Versionen nicht groß geändert und immer den Folgenden grundlegenden Aufbau:

olcAccess: {n} to "what" by "who" "access"

Was in vollendeter Form z.B. so aussehen kann:

olcAccess: {2}to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read by anonymous none

Das Beispiel ermöglicht den Mitgliedern der Gruppe “admins” Schreibrechte auf den Inhalt der Organisationseinheit “company”. Andere Benutzer haben Leserechte und Anonyme haben keinerlei Rechte.
Die {2} definiert die Reihenfolge der Verarbeitung. Die Access Control List wird von oben nach unten abgearbeitet. Regeln mit {1} greifen vor Regeln mit {2}, {3} etc… und werden auch so angewendet.
Eine Standardregel, die meist sehr weit oben in der ACL angesiedelt ist, lautet:

{1}to * by self write by dn="cn=admin,dc=netways,dc=org" write by * read

Diese Regel verhindert meist das folgende Regeln überhaupt Wirkungsvoll sind. Die Regel sagt aus das Überall der Benutzer “admin” Schreibrechte hat und jeder andere Benutzer Leserechte hat (und Benutzer auf die eigenen Objekte Schreibrechte haben). Ist diese Regel weit oben in der ACL angesiedelt haben die darauf folgenden Regeln meist keine Wirkung, daher empfiehlt es sich hier die Reihenfolge anzupassen.
Eine sehr detaillierte Anleitung über die Möglichkeiten der Definitionen gibt hier die OpenLDAP 2.4 Dokumentation: http://www.openldap.org/doc/admin24/access-control.html
Die Dokumentation entält, meiner Meinung nach, eine sehr gute und verständliche Beschreibung der “what” Definition:
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
dn.base=”ou=people,o=suffix” trifft 2
dn.one=”ou=people,o=suffix” trifft 3 und 5
dn.subtree=”ou=people,o=suffix” trifft 2, 3, 4 und 5
dn.children=”ou=people,o=suffix” trifft 3, 4 und 5
Welche unterschiedlichen Möglichkeiten der “what” “who” und “access” Definition man hat beschreibt das Schaubild unter “8.2. Access Control via Static Configuration”.
Bisschen was aus der Praxis…
Damit dieser Blogpost nicht allzu theoretisch wird ein paar Code snippets die das Thema ACL ggf. etwas leichter machen.
Definitionen zur ACL hinzfügen:

changetype: add
add: olcAccess
olcAccess: to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read

Neue Definitionen werden in der Liste ganz am Ende aufgeführt und bekommen immer die höchste Listenzahl {}
Definition in der ACL ändern:

changetype: modify
delete: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * search
-
add: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Definitionen abändern erfordert ein “delete: olcAccess” und ein “add: olcAccess”. Die “-” sind im LDIF wichtig.
Definition an bestimmter Stelle in ACL ändern:

changetype modify
delete: olcAccess
olcAccess: {1}
-
add: olcAccess
olcAccess: {1}to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Hier wird der Inhalt von {1} mit dem neuen überschrieben.
Noch was Gutes zum Schluß…
Das Backend cn=config kann mit der Zeit sehr groß und sehr komplex werden.
Insbesondere dann wenn die ACL sehr groß geworden ist.
Zur Administration des Backends ist es daher Empfehlenswert auf einen gut strukturieren und übersichtlichen LDAP Browser / Editor zurück zu greifen.
Ich verwende sehr gerne Apache Directory Studio oder unter Windows LDAPAdmin.
Eine Verbindung zur cn=config erfolgt über den administrativen Backendbenutzer (meist cn=Manager,cn=config oder cn=admin,cn=config) und über die BaseDN cn=config.