Oto samouczek dotyczący przypadku SELinux:
Sprawdź, czy SELinux jest aktywny:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Jeśli tak, pomocne może być sprawdzenie porównawcze. Na przykład serwer ma domyślny DocumentRoot w /var/www/html, ale chcemy go gdzie indziej /path/to/document/root.
Jeśli SELinux nie aktywnie bawi się z zasobem, ls -dZw katalogu pojawi się coś takiego:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
Z drugiej strony, jeśli zastosowane zostaną konteksty SELinux, ls -dZwygląda to bardziej jak:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Jeśli porównamy do działającego DocumentRoot, będzie to wyglądać mniej więcej tak:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Argumenty _ri _todnoszą się do -r( --rolei -t( --type)) chcon. Oto strona podręcznika:
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
Na pierwszy rzut oka może wydawać się, że poniższe działania działają, ale mogą nie.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Jeśli serwer WWW nadal nie widzi DocumentRoot, zauważ, że kontekst ma znaczenie aż do rootowania:
$ 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
W tym momencie serwer WWW może zobaczyć katalog.
Tak, nauczyłem się dziś trudnej drogi.
UWAGA: Zastosowanie chcon koncepcyjnie ma wadę w dokumentacji RedHat ( 5.6.1. Zmiany tymczasowe: chcon ), która stwierdza:
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.
Użyj semanage i restorecon, aby wprowadzić bardziej trwałe zmiany. Krótki przykład:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
W odniesieniu do restorecon , zauważ, że -F jest wymagany, aby wpływać na cały kontekst (tj. Użytkownika i typ). Ponadto -R oznacza rekurencyjne wprowadzanie zmian. Argumenty -v lub -p mogą pokazywać postępy w sposób pełny lub zwięzły. Użyj -FRnv, aby zobaczyć, co się stanie, bez wprowadzania żadnych zmian.
Po użyciu semanage w ten sposób można wyświetlić lokalne zmiany bezpieczeństwa za pomocą polecenia:
$ sudo semanage export
Dane wyjściowe eksportu semanage mogą zostać zapisane i wykorzystane przez import semanage, aby ułatwić zastosowanie zestawu zmian w różnych systemach.
UWAGA: Ta odpowiedź zapewnia najbardziej podstawowy kontekst typu dla witryny. Bezpieczeństwo może być znacznie bardziej szczegółowe. Na przykład zobacz listę typów, które można zastosować do stron serwera WWW za pomocą polecenia:
$ seinfo -t | grep http
UWAGA: Narzędzia takie jak semanage i seinfo mogą nie być domyślnie instalowane. Przynajmniej w niektórych dystrybucjach wymagane pakiety mogą mieć takie nazwy:
policycoreutils-python
setools-console
DocumentRoot, co może dać ci wgląd w to, co widzi serwer WWW. Można też sprawdzić inne katalogi na ścieżce, choć jeśli to naprawdę pod/var/www/te nie powinny być problemem