Seite wählen

NETWAYS Blog

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 lesen…

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.

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.