Schlagwort-Archive: RHEL

SELinux Booleans

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic1 im CentOS-Support-Forum verwiesen.

Im Einführungsartikel2 wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.3 4 5

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

apache_userdir_forbidden

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

apache_userdir_allowed

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)6, getsebool(8)7 und setsebool(8)8 verwiesen.

Benutzer die Ausführung eines Skripts mit sudo gestatten

In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo1 unterstützen.

Schritt 1: Skript und Benutzerkonto erstellen

Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:

#!/bin/bash
echo "Hallo Welt."

Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte auf darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.

Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:

sudo adduser USERNAME

Schritt 2: /etc/sudoers konfigurieren

Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.

Benutzer einer Gruppe hinzufügen

Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.

Benutzer in /etc/sudoers

Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.

Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.

# User privilege specification
USERNAME    ALL=/path/to/script.sh

Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.

Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.

Datei unter /etc/sudoers.d/ erstellen

Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.

Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.

Fazit

Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.

Support-Subskriptionen von SUSE und RedHat

Nachdem ich an dieser Stelle bereits ausführlich über das kommerzielle Angebot Ubuntu Advantage berichtet habe, möchte ich in diesem Artikel kurz die Support-Subskriptionen von SUSE und RedHat vorstellen.

Die Subskriptionen

Beim SUSE Linux Enterprise Server (SLES) sowie dem RedHat Enterprise Linux (RHEL) handelt es sich um kommerzielle Produkte, welche nur mit einer gültigen Subskription verwendet werden dürfen.

Mit einer Subskription erhält man neben dem Recht, das erworbene Enterprise Linux verwenden zu dürfen, auch Zugriff auf Software-Paketquellen und darin enthaltene Updates für das Betriebssystem und enthaltene Software. Darüber hinaus umfassen die Subskriptionen Zugang zu Wissensdatenbanken und zu technischem Support. Für letzteren legen die einzelnen Subskriptionen auch das jeweilige Service-Level-Agreement fest.

Im Unterschied zu Ubuntu Advantage umfassen die in der folgenden Tabelle dargestellten Subskriptionen keine Verwaltungs-Werkzeuge, wie z.B. das von Canonical angebotene Landscape. Diese können sowohl bei SUSE, als auch bei RedHat zusätzlich erworben werden.

Die folgende Tabelle bietet eine Übersicht über die gängigen Support-Subskriptionen für SLES und RHEL:

 SLES StandardSLES PriorityRHEL StandardRHEL Premium
Subskription für1-2 Sockets oder 1-2 VMs1-2 Sockets oder 1-2 VMs2 Sockets, 1 physischer Server oder 2 VMs2 Sockets, 1 physischer Server oder 2 VMs
Software Upgrades & UpdatesJaJaJaJa
Anzahl Supportanfragenunbegrenztunbegrenztunbegrenztunbegrenzt
ZugangChat, Telefon und E-MailChat, Telefon und E-MailWeb und TelefonWeb und Telefon
Verfügbarkeit12x524x78x524x7
Reaktionszeiten
Stufe 12 Std.1 Std.1 Geschäfts-Std.1 Std.
Stufe 24 Std.2 Std.4 Geschäfts-Std.2 Std.
Stufe 31 Werktag4 Std.1 Werktag4 Std.
Stufe 41 Werktag1 Werktag2 Werktage8 Std. initial / 2 Werktage ongoing
Listenpreis pro Jahr670 EUR1.250 EUR700 EUR1.139 EUR

Die in der Tabelle enthaltenen Informationen beziehen sich auf die bei Veröffentlichung dieses Artikels aktuellen Angaben der Distributionen.

Die dargestellten Subskriptionen gelten für je einen physischen Server mit 1-2 CPU Sockets oder 2 VMs. Besitzt man einen physischen Server mit mehr als 2 CPU-Sockets muss eine Subskription mehrfach erworben werden, um diesen Server abzudecken. Besitzt ein Server bspw. 4 CPU-Sockets, muss die Subskription für diesen Server zweimal erworben werden. Möchte man die benötigte Anzahl der Subskriptionen für virtuelle Maschinen bestimmen, so lautet die Formel Anzahl VMs / 2 = Anzahl benötigter Subskriptionen.

Bei den Subskriptionen für virtuelle Maschinen spielt es dabei keine Rolle, ob diese mit Hilfe von VMware, Microsoft Hyper-V, XEN oder KVM betrieben werden.

Ab einer bestimmten Menge VMs ist es kostengünstiger statt Subskriptionen für einzelne VMs solche einzusetzen, welche das gesamte virtuelle Datacenter abdecken:

 SUSE für hochdichte VirtualisierungsumgebungenRed Hat Enterprise Linux for Virtual Datacenters
StandardPriorityStandardPremium
Gültig für1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen
Listenpreis für 1 Jahr1.330 EUR2.490 EUR2.192 EUR3.507 EUR

Die in der obigen Tabelle dargestellten Subskriptionen gelten jeweils für einen physischen Host, auf welchem virtuelle Maschinen ausgeführt werden. Zum Beispiel müssen für einen VMware vSphere-Cluster bestehend aus drei physischen Hosts mit je 1-2 CPU Sockets dann drei der entsprechenden Subskriptionen erworben werden. Auch hier gilt wieder, besitzt ein Host mehr als 2 CPU-Sockets, muss die jeweilige Subskription entsprechend mehrmals für diesen Host gekauft werden, bis die Gesamtzahl der CPU-Sockets pro Host abgedeckt ist.

Der Vorteil dieses Subskriptions-Modells liegt darin, dass hiermit beliebig viele VMs in einem virtuellen Datacenter betrieben werden können. Wird das virtuelle Datacenter jedoch um einen physischen Host erweitert, muss für diesen ebenfalls eine Subskription erworben werden, obwohl weiterhin die gleiche Anzahl VMs darauf ausgeführt wird. Je nach Kostenbetrachtung kann dies einen Nachteil darstellen.

Die folgenden Diagramme stellen den Break Even der jeweiligen Subskriptionen dar. Sie wurden für die Verwendung eines virtuellen Datacenters bestehend aus 3 Hosts mit jeweils 1-2 CPU Sockets berechnet.

Bei den in diesem Artikel verwendeten Preisen handelt es sich um Listenpreise. Beim Kauf von Subskriptionen über einen Fachhändler können je nach Umfang der Bestellung meist noch Rabatte gewährt werden.

Neben den hier betrachteten Subskriptionen existieren noch weitere für die Bereiche Forschung und Lehre sowie zur Erweiterung des Leistungsumfangs. Weitere Informationen dazu finden sich über die Links am Ende dieses Artikels.

Die in diesem Artikel enthaltenen Informationen wurden im Rahmen einer Linux-Evaluierung im Hochschulrechenzentrum der Uni Bielefeld erhoben.

Links