CentOS 7 - Répertoires créés via VSFTPD n'héritant pas des contextes SELinux

Notre entreprise dispose d'un serveur Web avec CentOS 7 et nos clients gèrent leurs sites Web via FTP (vsftpd). SELinux est en mode d'application.

Le problème est que les données créées / téléchargées via VSFTPD n'héritent pas du contexte SELinux approprié. Laisse-moi expliquer.

Par exemple, pour les sites WordPress, le serveur dispose déjà de quelques règles qui peuvent être vues à l'aide semanage fcontext -l |grep '/var/www', qui sont:

/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

Ainsi, lorsque je copie un site WordPress, disons à partir d'un autre serveur dans un répertoire dans /var/www/html/SSH, les dossiers wp-content/et wp-content/uploads/ont le httpd_sys_rw_content_tcontexte de sécurité approprié . TOUTEFOIS, lorsque ces dossiers sont créés via FTP, le contexte qu'ils obtiennent est httpd_sys_content_t(pas de rw ). Cela signifie que les sites que nos clients téléchargent sur le serveur ne peuvent pas écrire dans ces répertoires même s'ils donnent des autorisations d'écriture à l'utilisateur / groupe apache, donc l'administrateur WordPress ne fonctionne pas. Ainsi, quand ils téléchargent un site, ils doivent nous demander de l'aide pour résoudre ce problème, ce qui est une perte de temps pour toutes les personnes impliquées.

Disons que le client a téléchargé son site dans httpdocs, si via SSH je fais mv httpdocs/ httpdocs.2/ && cp -pr httpdocs.2/ httpdocs/ && rm httpdocs.2/ -frle problème est résolu, donc il n'y a rien de mal avec les données.

Je peux également faire restorecon -Rv httpdocs/pour résoudre le problème.

Donc, la question est: comment puis-je faire en sorte que les répertoires créés / téléchargés via VSFTPD héritent des contextes SELinux appropriés, tout comme ils sont hérités lorsque les répertoires sont créés / téléchargés via SSH?

Il existe une différence entre l'étiquetage par défaut qui se produit au moment de l'exécution et la stratégie de post-étiquetage basée sur l'expression régulière qui s'applique sur le serveur.

Ce que vous notez ici:

/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

Est la politique de post-étiquetage.

Ce que vous discutez dans votre problème se rapporte en fait à la stratégie d'exécution.

Lorsqu'une entrée est créée dans un répertoire à l'aide de SELinux, les règles régissant le libellé du fichier ou du répertoire ne sont pas dictées par les expressions régulières que vous citez, mais par les autres règles comme suit (je pense que c'est le bon ordre, mais il est possible qu'il ait manqué quelque chose) .

1. Il existe une type_transitionrègle nommée explicite .
2. Il existe une type_transitionrègle explicite non nommée .
3. Héritez le même contexte que le répertoire parent.
4. Appliquez le default_context.

Ainsi, lorsque je copie un site WordPress, disons d'un autre serveur dans un répertoire dans / var / www / html / par SSH, les dossiers wp-content / et wp-content / uploads / ont le contexte de sécurité httpd_sys_rw_content_t approprié.

Donc, oui, il le fait, mais pas pour la raison pour laquelle vous le pensez. Certainement pas à cause de la politique de post-étiquetage.

Cela se produit car une type_transitionrègle nommée spécifique existe qui fournit ce comportement.

$ sesearch -C -T -s unconfined_t -t httpd_sys_content_t -c dir

Found 4 named file transition filename_trans:
type_transition unconfined_t httpd_sys_content_t : dir httpd_sys_rw_content_t "wp-content"; 
type_transition unconfined_t httpd_sys_content_t : dir httpd_sys_rw_content_t "smarty"; 
type_transition unconfined_t httpd_sys_content_t : dir httpd_sys_rw_content_t "uploads"; 
type_transition unconfined_t httpd_sys_content_t : dir httpd_sys_rw_content_t "upgrade"; 

C'est essentiellement dire.

• Si vous êtes unconfined_t et
• Si vous effectuez une action dans le type cible httpd_sys_content_t et
• Si la classe de la nouvelle entrée est un répertoire et
• Si le nom de la nouvelle entrée est « upload » puis
• Le nouveau type est httpd_sys_rw_content_t

La raison pour laquelle cela fonctionne pour SSHD est qu'après vous être connecté, le contexte source unconfined_tauquel cette règle s'applique s'applique.

Cela ne fonctionne pas pour le service FTP car le contexte source de ce service est très probablement ftpd_tsans règle de correspondance.

En tant que tel, vous devrez modifier la stratégie pour modifier le comportement de SELinux afin d'honorer également les décisions de fichier nommées que vous voyez dans les autres entrées pour FTP également.

Dans Fedora 23 au moins, il existe une interface pour permettre cela, un module de politique comme celui-ci le ferait.

policy_module(local_ftpd, 7.2.0)

require {
  type ftpd_t;
}

apache_filetrans_named_content(ftpd_t)

Vous pouvez le charger en vous assurant que le selinux-policy-develpackage est installé et en cours d'exécution make -f /usr/share/selinux/devel/Makefile load.