Implementierung der obligatorischen Zugriffskontrolle mit SELinux oder AppArmor unter Linux
Um die Einschränkungen der standardmäßigen ugo/rwx-Berechtigungen und Zugriffskontrolllisten zu überwinden und die Sicherheitsmechanismen zu erhöhen, hat die US-amerikanische National Security Agency (NSA) eine flexible MAC-Methode (Mandatory Access Control) entwickelt, die als SELinux (kurz für Security Enhanced Linux) bekannt ist), um unter anderem die Fähigkeit von Prozessen, auf Systemobjekte (wie Dateien, Verzeichnisse, Netzwerkports usw.) zuzugreifen oder diese auszuführen, auf die geringstmögliche Berechtigung zu beschränken, während spätere Änderungen an diesem Modell weiterhin möglich sind.
Ein weiterer beliebter und weit verbreiteter MAC ist AppArmor, der zusätzlich zu den von SELinux bereitgestellten Funktionen einen Lernmodus enthält, der es dem System ermöglicht, zu "lernen", wie sich eine bestimmte Anwendung verhält, und durch die Konfiguration von Profilen für eine sichere Anwendungsnutzung Grenzen zu setzen.
In CentOS 7 ist SELinux in den Kernel selbst integriert und standardmäßig im Enforcement-Modus aktiviert (mehr dazu im nächsten Abschnitt), im Gegensatz zu openSUSE und Ubuntu, die AppArmor verwenden.
In diesem Artikel erklären wir Ihnen die Grundlagen von SELinux und AppArmor und wie Sie je nach gewählter Distribution eines dieser Tools zu Ihrem Vorteil nutzen können.
Einführung in SELinux und wie man es unter CentOS 7 verwendet
Security Enhanced Linux kann auf zwei verschiedene Arten betrieben werden:
- Erzwingung: SELinux verweigert den Zugriff basierend auf SELinux-Richtlinienregeln, einer Reihe von Richtlinien, die die Sicherheits-Engine steuern.
- Zulässig: SELinux verweigert den Zugriff nicht, aber Verweigerungen werden für Aktionen protokolliert, die im Erzwingungsmodus verweigert worden wären.
SELinux kann auch deaktiviert werden. Obwohl es sich nicht um einen Betriebsmodus handelt, ist er dennoch eine Option. Es ist jedoch besser, den Umgang mit diesem Tool zu erlernen, als es einfach zu ignorieren. Behalten Sie es im Hinterkopf!
Um den aktuellen Modus von SELinux anzuzeigen, verwenden Sie getenforce. Wenn Sie den Betriebsmodus umschalten möchten, verwenden Sie setenforce 0 (um ihn auf Permissive zu setzen) oder setenforce 1 (Erzwingen).
Da diese Änderung einen Neustart nicht überlebt, müssen Sie die Datei /etc/selinux/config bearbeiten und die Variable SELINUX entweder auf enforceing, permissive oder disabled setzen, um Persistenz über Neustarts hinweg zu erreichen:
Nebenbei bemerkt, wenn getenforce Disabled zurückgibt, müssen Sie /etc/selinux/config mit dem gewünschten Betriebsmodus bearbeiten und neu starten. Andernfalls können Sie den Betriebsmodus mit setenforce nicht einstellen (oder umschalten).
Eine der typischen Anwendungen von setenforce besteht darin, zwischen den SELinux-Modi umzuschalten (von enforcing zu permissive oder umgekehrt), um eine Anwendung zu beheben, die sich schlecht verhält oder nicht wie erwartet funktioniert. Wenn es funktioniert, nachdem Sie SELinux auf den permissiven Modus festgelegt haben, können Sie sicher sein, dass es sich um ein SELinux-Berechtigungsproblem handelt.
Zwei klassische Fälle, in denen wir es höchstwahrscheinlich mit SELinux zu tun haben werden, sind:
- Ändern des Standardports, an dem ein Daemon lauscht.
- Festlegen der DocumentRoot-Direktive für einen virtuellen Host außerhalb von /var/www/html.
Werfen wir einen Blick auf diese beiden Fälle anhand der folgenden Beispiele.
BEISPIEL 1: Ändern des Standardports für den sshd-Daemon
Eines der ersten Dinge, die die meisten Systemadministratoren tun, um ihre Server zu sichern, ist das Ändern des Ports, auf dem der SSH-Daemon lauscht, vor allem, um Port-Scanner und externe Angreifer abzuschrecken. Um dies zu tun, verwenden wir die Port-Direktive in /etc/ssh/sshd_config gefolgt von der neuen Portnummer wie folgt (in diesem Fall verwenden wir Port 9999):
Port 9999
Nachdem wir versucht haben, den Dienst neu zu starten und seinen Status zu überprüfen, werden wir feststellen, dass er nicht gestartet werden konnte:
systemctl restart sshd
systemctl status sshd
Wenn wir einen Blick auf /var/log/audit/audit.log werfen, werden wir sehen, dass sshd von SELinux daran gehindert wurde, auf Port 9999 zu starten, da dies ein reservierter Port für den JBoss-Management-Dienst ist (SELinux-Protokollnachrichten enthalten das Wort "AVC", damit sie von anderen Nachrichten leicht identifiziert werden können):
cat /var/log/audit/audit.log | grep AVC | tail -1
Zu diesem Zeitpunkt würden die meisten Leute wahrscheinlich SELinux deaktivieren, aber wir werden es nicht tun. Wir werden sehen, dass es einen Weg gibt, wie SELinux und sshd, die auf einem anderen Port lauschen, in Harmonie miteinander leben können. Stellen Sie sicher, dass Sie das Paket policycoreutils-python installiert haben, und führen Sie es aus:
yum install policycoreutils-python
Zum Anzeigen einer Liste der Ports, an denen SELinux das Abhören von sshd zulässt. In der folgenden Abbildung sehen wir auch, dass Port 9999 für einen anderen Dienst reserviert war und wir ihn daher vorerst nicht zum Ausführen eines anderen Dienstes verwenden können:
semanage port -l | grep ssh
Natürlich könnten wir einen anderen Port für SSH wählen, aber wenn wir sicher sind, dass wir diesen speziellen Rechner nicht für JBoss-bezogene Dienste verwenden müssen, können wir dann die bestehende SELinux-Regel ändern und diesen Port stattdessen SSH zuweisen:
semanage port -m -t ssh_port_t -p tcp 9999
Danach können wir den ersten semanage-Befehl verwenden, um zu überprüfen, ob der Port korrekt zugewiesen wurde, oder die -lC-Optionen (kurz für list custom):
semanage port -lC
semanage port -l | grep ssh
Wir können jetzt SSH neu starten und uns über Port 9999 mit dem Dienst verbinden. Beachten Sie, dass diese Änderung einen Neustart überlebt.
BEISPIEL 2: Auswahl eines DocumentRoot außerhalb von /var/www/html für einen virtuellen Host
Wenn Sie einen virtuellen Apache-Host mit einem anderen Verzeichnis als /var/www/html als DocumentRoot einrichten müssen (z. B. /websrv/sites/gabriel/public_html):
DocumentRoot “/websrv/sites/gabriel/public_html”
Apache weigert sich, den Inhalt bereitzustellen, da der index.html mit dem Typ default_t SELinux gekennzeichnet wurde, auf den Apache nicht zugreifen kann:
wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html
Wie im vorherigen Beispiel können Sie den folgenden Befehl verwenden, um zu überprüfen, ob es sich tatsächlich um ein SELinux-bezogenes Problem handelt:
cat /var/log/audit/audit.log | grep AVC | tail -1
Gehen Sie folgendermaßen vor, um die Beschriftung von /websrv/sites/gabriel/public_html rekursiv in httpd_sys_content_t zu ändern:
semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"
Der obige Befehl gewährt Apache schreibgeschützten Zugriff auf dieses Verzeichnis und seinen Inhalt.
Um die Richtlinie anzuwenden (und die Änderung der Bezeichnung sofort wirksam zu machen), gehen Sie wie folgt vor:
restorecon -R -v /websrv/sites/gabriel/public_html
Nun sollten Sie in der Lage sein, auf das Verzeichnis zuzugreifen:
wget http://localhost/index.html
Weitere Informationen zu SELinux finden Sie im Fedora 22 SELinux und Administratorhandbuch.