Voici une approche didactique du cas SELinux:
Découvrez si SELinux est actif:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Dans l'affirmative, une vérification comparative pourrait être utile. Par exemple, un serveur a un DocumentRoot par défaut sur /var/www/html
, mais nous le voulons ailleurs comme /path/to/document/root
.
Si SELinux ne joue pas activement avec la ressource, ls -dZ
le répertoire affichera quelque chose comme:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
En revanche, si des contextes SELinux sont appliqués, cela ls -dZ
ressemble plus à:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Si nous comparons à un DocumentRoot fonctionnel, cela ressemblerait à quelque chose comme:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Les arguments _r
et se _t
rapportent à -r
( --role
et -t
( --type
) à chcon
. Voici une page de manuel réduite:
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
À première vue, les éléments suivants peuvent sembler fonctionner, mais peuvent ne pas fonctionner.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Si le serveur Web ne peut toujours pas voir le DocumentRoot, notez que le contexte est important jusqu'à la racine:
$ 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
À ce stade, le serveur Web peut voir le répertoire.
Oui, j'ai appris à la dure ce soir.
REMARQUE: L'utilisation de chcon a conceptuellement un inconvénient selon la documentation RedHat ( 5.6.1. Modifications temporaires: chcon ) qui stipule:
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.
Utilisez semanage et restorecon pour apporter des modifications plus permanentes. Un bref exemple:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
En ce qui concerne la restauration , notez que -F est requis pour affecter l'ensemble du contexte (c'est-à-dire l'utilisateur et le type). De plus, -R signifie apporter des modifications récursivement. Les arguments -v ou -p peuvent montrer la progression de façon verbeuse ou laconique. Utilisez -FRnv pour voir ce qui se passerait sans apporter de modifications.
Une fois le semanage utilisé de cette manière, il est possible de visualiser les modifications de sécurité locales avec une commande comme:
$ sudo semanage export
La sortie de l' exportation de semanage peut être enregistrée et utilisée par l' importation de semanage pour faciliter l'application d'un ensemble de modifications à divers systèmes.
REMARQUE: cette réponse fournit le contexte de type le plus basique pour un site. La sécurité peut être beaucoup plus granulaire. Par exemple, consultez une liste de types pouvant s'appliquer aux pages de serveur Web avec une commande comme:
$ seinfo -t | grep http
REMARQUE: les utilitaires tels que semanage et seinfo peuvent ne pas être installés par défaut. Au moins sur certaines distributions, les packages requis peuvent être nommés quelque chose comme ceci:
policycoreutils-python
setools-console
DocumentRoot
, cela pourrait vous donner un aperçu de ce que le serveur Web voit. Vous pouvez également vouloir vérifier les autres répertoires le long du chemin, mais si c'est vraiment sous/var/www/
ceux-ci, cela ne devrait pas être un problème