Hier ist ein Tutorial-Ansatz für den SELinux-Fall:
Finden Sie heraus, ob SELinux aktiv ist:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
In diesem Fall kann eine vergleichende Überprüfung hilfreich sein. Zum Beispiel hat ein Server einen Standard-DocumentRoot unter /var/www/html, aber wir möchten ihn woanders haben /path/to/document/root.
Wenn SELinux nicht aktiv mit der Ressource kommuniziert, wird ls -dZim Verzeichnis Folgendes angezeigt:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
Wenn SELinux-Kontexte angewendet werden, ls -dZsieht dies eher so aus:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Wenn wir es mit einem funktionierenden DocumentRoot vergleichen, würde es ungefähr so aussehen:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Die Argumente _rund _tbeziehen sich auf -r( --roleund -t( --type) auf chcon. Hier ist eine reduzierte Manpage:
NAME
chcon - change file security context
SYNOPSIS
chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
DESCRIPTION
Change the security context of each FILE to CONTEXT. With --reference,
change the security context of each FILE to that of RFILE.
--reference=RFILE
use RFILE's security context rather than specifying a CONTEXT value
-R, --recursive
operate on files and directories recursively
Auf den ersten Blick scheint das Folgende zu funktionieren, aber möglicherweise nicht.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Wenn der Webserver den DocumentRoot weiterhin nicht sehen kann, beachten Sie, dass der Kontext bis zum Root-Verzeichnis von Bedeutung ist:
$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path
Zu diesem Zeitpunkt kann der Webserver das Verzeichnis sehen.
Ja, ich habe heute Abend auf die harte Tour gelernt.
HINWEIS: Die konzeptionelle Verwendung von chcon hat laut RedHat-Dokumentation ( 5.6.1. Temporäre Änderungen: chcon ) folgende Nachteile :
The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.
Verwenden Sie semanage und restorecon , um dauerhaftere Änderungen vorzunehmen. Ein kurzes Beispiel:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Beachten Sie in Bezug auf restorecon , dass -F erforderlich ist, um den gesamten Kontext (dh Benutzer und Typ) zu beeinflussen. Auch -R Mittel , um Änderungen rekursiv zu machen. Die Argumente -v oder -p können den Fortschritt entweder ausführlich oder knapp anzeigen. Verwenden Sie -FRnv, um zu sehen, was passieren würde, ohne Änderungen vorzunehmen.
Sobald semanage auf diese Weise verwendet wird, können lokale Sicherheitsänderungen mit einem Befehl wie dem folgenden angezeigt werden :
$ sudo semanage export
Die Ausgabe des Semanage-Exports kann gespeichert und vom Semanage-Import verwendet werden, um das Anwenden einer Reihe von Änderungen auf verschiedene Systeme zu vereinfachen.
HINWEIS: Diese Antwort bietet einen grundlegendsten Typkontext für eine Site. Sicherheit kann viel detaillierter sein. Eine Liste der Typen, die auf Webserverseiten angewendet werden können, finden Sie beispielsweise mit folgenden Befehlen:
$ seinfo -t | grep http
HINWEIS: Dienstprogramme wie semanage und seinfo werden möglicherweise nicht standardmäßig installiert. Zumindest bei einigen Distributionen können erforderliche Pakete wie folgt benannt werden:
policycoreutils-python
setools-console
DocumentRootDies gibt Ihnen möglicherweise einen Einblick in die Darstellung des Webservers. Vielleicht möchten Sie auch die anderen Verzeichnisse entlang des Pfads überprüfen, aber wenn es wirklich darunter ist/var/www/, sollte dies kein Problem sein