SELinux fcontext après svn checkout

Question

Je voudrais commencer par dire qu'il n'y a pas vraiment de problème et que tout fonctionne comme je m'y attendais, mais je suis confronté à un comportement étrange que je ne peux pas expliquer, alors je cherche des informations .

Le comportement impair est observé avec la façon dont SELinux applique les définitions de mappage fcontext.

Permettez-moi de commencer par l'impression SELinux politiques de fcontext qui applique à mon cas:

[root@ip-10-0-0-40 wp-content]# semanage fcontext -l | grep "^/var/www.*httpd_sys_rw_content_t:s0\s$" 
/var/www/svn(/.*)?         all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html(/.*)?/uploads(/.*)?     all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html(/.*)?/wp-content(/.*)?    all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html(/.*)?/sites/default/files(/.*)?  all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html(/.*)?/sites/default/settings\.php regular file  system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/moodledata(/.*)?       all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/moodle/data(/.*)?       all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/gallery/albums(/.*)?      all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html/owncloud/data(/.*)?     all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html/configuration\.php     all files   system_u:object_r:httpd_sys_rw_content_t:s0 

Comme vous pouvez le voir sur la commande, je suis intéressé par les politiques fcontext permettant httpd d'écrire à l'intérieur /var/www .

J'installe une installation de WordPress, donc mes yeux verrouiller sur ces politiques:

/var/www/html(/.*)?/uploads(/.*)?     all files   system_u:object_r:httpd_sys_rw_content_t:s0 
/var/www/html(/.*)?/wp-content(/.*)?    all files   system_u:object_r:httpd_sys_rw_content_t:s0 

De la RegExp politique, je peux desifer quelle structure le répertoire que je dois avoir. Créons un répertoire pour le projet et la caisse.

[root@ip-10-0-0-40 /]# mkdir -p /var/www/html/sun 
[root@ip-10-0-0-40 /]# cd /var/www/html/sun 
[root@ip-10-0-0-40 sun]# svn co http://server/ . 

Vérifions si nous avons droit fcontext appliqué:

[root@ip-10-0-0-40 sun]# cd /var/www/html/sun/public/wp-content 
[root@ip-10-0-0-40 wp-content]# ls -Z 
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads 

Great! Juste pour un intérêt et revérifier, essayons de restaurer fcontext et de voir ce qui se passe:

[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/html/sun/ 
[root@ip-10-0-0-40 wp-content]# ls -Z 
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads 

Great! Fonctionne comme prévu Pour terminer le test, simulons une panne attendue. Créons un répertoire de projet en dehors de /html/, comme ici: /var/www/sun et passez à la caisse.

[root@ip-10-0-0-40 wp-content]# mkdir -p /var/www/sun 
[root@ip-10-0-0-40 wp-content]# cd /var/www/sun/ 
[root@ip-10-0-0-40 sun]# svn co http://server/ . 

Vérifions si nous avons droit fcontext appliqué:

[root@ip-10-0-0-40 sun]# cd /var/www/sun/public/wp-content/ 
[root@ip-10-0-0-40 wp-content]# ls –Z 
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads 

Odd, je me attendais à voir httpd_sys_content_t (par défaut fcontext), essayons de restaurer par défaut:

[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/sun 
...Output omitted 
[root@ip-10-0-0-40 wp-content]# ls -Z 
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 languages 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mu-plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 plugins 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 themes 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 uploads 

Utilisation de restorecon pour /var/www/sun fonctionne comme prévu, cependant ... le puzzle est:

Pourquoi svn co dans/var/www/sun a utilisé des politiques non existantes? Le match de la politique fcontext mais pas l'emplacement pour cela:

/var/www/html(/.*)?/wp-content(/.*)?    all files   system_u:object_r:httpd_sys_rw_content_t:s0 

Outre l'indice .php ont differect fcontext, mais les répertoires ont le même: httpd_sys_rw_content_t

Answer 1

J'ai eu la même question: « Pourquoi wp-content répertoires étiquetés automatiquement avec httpd_sys_rw_content_t même en dehors des règles de fcontext pour /var/www/html? ". Cependant, j'ai maintenant trouvé la réponse et j'ai pensé la poster ici.

Il est provoqué par une fonctionnalité de SELinux appelée Filename Transitions qui est un mécanisme de politique pour aider à créer des fichiers et des répertoires correctement étiquetés.

Dans votre exemple, le répertoire /var/www/soleil/ publique hérite httpd_sys_content_t vers le bas de /var/www.

Ordinairement, un répertoire appelé wp-content qui est créé à l'intérieur d'un /var/www/soleil/ publique serait également hériter httpd_sys_content_t.

Mais apache.if il y a une règle de transition de nom de fichier qui dit que tout répertoire appelé « wp-content » qui aurait été créé avec httpd_sys_content_t devrait plutôt être créé comme httpd_sys_rw_content_t

En CentOS 7, installez paquet selinux-policy-devel et vous pouvez voir la définition dans /usr/share/selinux/devel/include/contrib/apache.if

filetrans_pattern($1, httpd_sys_content_t, httpd_sys_rw_content_t, dir, "wp-content") 

Vous pouvez tester la théorie comme suit:

[root@dt-laptop-centos7 /]# mkdir junk 
[root@dt-laptop-centos7 /]# ls -aldZ junk 
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 junk 
[root@dt-laptop-centos7 /]# chcon -t httpd_sys_content_t junk 
[root@dt-laptop-centos7 /]# ls -aldZ junk 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 junk 
[root@dt-laptop-centos7 /]# cd junk 
[root@dt-laptop-centos7 junk]# mkdir wp-otherdir 
[root@dt-laptop-centos7 junk]# mkdir wp-content 
[root@dt-laptop-centos7 junk]# ls -alZ 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 . 
dr-xr-xr-x. root root system_u:object_r:root_t:s0  .. 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content 
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 wp-otherdir 

Vous pouvez voir que wp-content a son contexte automatiquement mis à httpd_sys_rw_content_t alors que wp-autre_rep hérite juste httpd_sys_content_t