Ось підручник підхід до справи SELinux:
Дізнайтеся, чи активний SELinux:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Якщо так, деякі порівняльні перевірки можуть допомогти. Наприклад, у сервера є DocumentRoot за замовчуванням /var/www/html, але ми хочемо, щоб він був десь іншим, як /path/to/document/root.
Якщо SELinux активно не возиться з ресурсом, ls -dZу каталозі буде показано щось на кшталт:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
З іншого боку, якщо застосовано контексти SELinux, це ls -dZвиглядає більше:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Якщо порівняти з робочим DocumentRoot, це виглядатиме приблизно так:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Аргументи _rі _tвідносяться до -r( --roleі -t( --type) аргументів chcon. Ось перерізна сторінка, що випадає:
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
На перший погляд, наступне може здатися спрацьованим, але не може.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Якщо веб-сервер все ще не бачить DocumentRoot, зауважте, що контекст має значення аж до кореня:
$ 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
У цей момент веб-сервер може побачити каталог.
Так, я навчився важкого шляху сьогодні ввечері.
ПРИМІТКА: Використання chcon концептуально має мінус на документацію RedHat ( 5.6.1. Тимчасові зміни: chcon ), яка зазначає:
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.
Використання semanage і restorecon зробити більш постійні зміни. Короткий приклад:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Що стосується відновленняconcon , зауважте, що -F повинен впливати на весь контекст (тобто користувача та тип). Також -R означає вносити зміни рекурсивно. Аргументи -v або -p можуть демонструвати прогрес як у багатослівній, так і в стислій формі. Використовуйте -FRnv, щоб побачити, що станеться без фактичних змін.
Після того, як семанювання використовується таким чином, можна переглянути локальні зміни безпеки за допомогою команди типу:
$ sudo semanage export
Вихід semanage експорту може бути збережений і використаний semanage імпорту , щоб зробити його простіше застосовувати набір змін в різні системи.
ПРИМІТКА. Ця відповідь надає основний контекст типу для сайту. Безпека може бути набагато більш детальною. Наприклад, перегляньте список типів, які можна застосувати до сторінок веб-сервера з такою командою:
$ seinfo -t | grep http
ПРИМІТКА. Утиліти, такі як semanage та seinfo, можуть не встановлюватися за замовчуванням. Принаймні, в деяких дистрибутивах необхідні пакети можуть бути названі приблизно так:
policycoreutils-python
setools-console
DocumentRoot, це може дати вам деяке уявлення про те, що бачить веб-сервер. Ви також можете перевірити інші каталоги на шляху, хоча якщо це дійсно під/var/www/тими, не повинно бути проблем