SELinux : Security-Enhanced Linux

Le noyau linux prend souvent en charge par défaut les politiques SE Linux.

Pour installer les utilitaires sous Debian 5 :

apt-get install selinux-basics selinux-policy-default selinux-policy-refpolicy-targeted selinux-utils selinux-policy-doc

Activer SELinux en mode permissive :

setenforce 0
selinux-activate

Pour renforcer la sécurité :

setenforce 1

Pour connaître l'état de SELinux :

sestatus

Pour avoir quelques statistiques sur SELinux :

seinfo

Pour commencer, quelques commandes pour relever les contextes de sécurité sur les programmes et les fichiers.

Pour connaitre le contexte de sécurité d'un fichier, la commande ls dispose de l'option -Z :

ls -Z

Pour connaitre les contextes de sécurité des programmes en cours d'exécution :

ps -ef -Z

Pour connaitre le rôle et la responsabilité de l'utilisateur connecté :

id -Z

Les règles de sécurité de SE Linux peuvent être fastidieuses à écrire. Cependant des modules contenant des règles préétablies pour chacun des programmes sont disponibles sous forme de packages .pp. SE Linux dispose donc d'une commande pour ajouter ou supprimer ces modules.

Pour lister les modules de SE Linux :

semodule -l

Pour installer le module pour apache :

semodule -v -i /usr/share/selinux/default/apache.pp

Pour recharger un module après l'avoir modifié:

semodule -R /usr/share/selinux/default/apache.pp

Pour supprimer le module pour apache :

semodule -v -r apache

Vous êtes développeur, vous souhaitez créer vos propres règles SELinux pour votre programme vous devez compiler vos propres module. Voir la section plus bas

A savoir : Un utilisateur est mappé sur un utilisateur SELinux. Un utilisateur SELinux est confiné dans un rôle ou plusieurs rôle (voir section suivante)

Pour connaitre le mapping Utilisateur et Utilisateur SELinux :

semanage login -l

Nous allons ici, mapper le compte benoit sur staff_u afin que Benoit puisse bénéficier en cas de besoin du rôle de l'utilisateur sysadm_u

Pour mapper l'utilisateur benoit avec l'utilisateur SELinux sysadm_u :

semanage login -a -s staff_u -r s0-s0:c0.c1023 benoit

Lorsque vous changez le mapping d'un utilisateur, il faut également appliquer le nouveau contexte par défaut sur son répertoire home (cette commande est abordée plus bas) :

restorecon -R /home/benoit

Si vous souhaitez modifier le mapping du compte pour qu'il ait directement tous les privilèges, mappez l'utilisateur sur sysadm_u, exemple :

semanage login -m -s sysadm_u benoit
restorecon -R /home/benoit

A savoir : par défaut, l'utilisateur SELinux sysadm_u ne peut pas se connecter directement en SSH.

Si vous ne souhaitez plus que le compte benoit soit mappé (en réalité, il sera remappé sur user_u) :

semanage login -d benoit

Comme vu dans la section précédente, les utilisateurs SELinux sont confinés dans des rôles. C'est au travers d'un rôle qu'un utilisateur aura les droits sur le système.

Pour lister les rôles que peuvent prendre les utilisateurs SELinux :

semanage user -l

Interprétons le résultat suivant :

staff_u         staff      s0         s0-s0:c0.c1023                 staff_r sysadm_r
user_u          user       s0         s0                             user_r

• L'utilisateur staff_u peut prendre le rôle staff_r et sysadm_r.
• L'utilisateur user_u ne peut prendre que le rôle user_r

Un utilisateur qui souhaite avoir les droits root sur le système, doit d'une part passer root via la commande su - mais également changer de rôle via la commande newrole si son compte SE Linux le permet (staff_u est autorisé, mais user_u ne l'est pas). Un utilisateur mappé sur staff_u, devra suivre la procédure suivante pour passer root :

su - 
newrole -r sysadm_r

La commande ci-dessous permet de lister les transitions de rôle :

sesearch --role_allow

Interprétons la ligne :

allow sysadm_r user_r;

L'utilisateur SE Linux ayant le rôle sysadm_r peut intervenir sur les objets nécessitant le rôle user_r. Attention, à ne pas confondre avec le rôle que peut prendre un utilisateur. Par exemple, L'utilisateur sysadm_u peut pas prendre le rôle de user_u.

C'est principalement au travers des types que SE Linux autorise ou pas les actions.

• Dans SELinux un domaine fait référence à un processus, exemples httpd_t, sshd_t…
• Dans SELinux un type fait référence à un fichier, exemples httpd_exec_t sur le fichier binaire d'apache, httpd_sys_content_t sur des pages html…

Pour lister par exemple tout ce que peut faire le processus labellisé initrc_t sur d'autres processus labellisés :

sesearch --allow -s initrc_t -c process

Interprétons la ligne suivante résultant de la commande :

allow initrc_t sshd_t : process transition ;

Le processus labellisé initrc_t peut transiter vers le processus labelliser sshd_t afin de pouvoir le lancer.

Pour lister par exemple tout ce que peut faire le processus labélisé httpd_t sur les fichiers

sesearch --allow -s httpd_t -c file

Interprétons la ligne suivante résultant de la commande :

allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock } ;

Un fichier labéllisé httpd_sys_content_t autorise le processus labellisé httpd_t de faire les actions ioctl read getattr lock sur le fichier.

Pour lister les points d'entrée des processus et des utilisateurs SELinux :

sesearch --allow -c file -p entrypoint

Les points d'entrée représentent le passage obligé d'un processus ou d'un utilisateur sur un fichier

Sous SELinux les données peuvent être classifiées selon leur sensibilité et leur catégorie :

• La sensibilité est identifiée par un s et peut permettre de définir si le fichier est public, confidentielle, très confidentielle etc…
• La catégorie est identifiée par un c et peut permettre de définir si le fichier fait référence au projet_d_entreprise, bilan_de_la_société etc…

En fonction du niveau de sensibilité ou de la catégorie on défini un chiffre. Par défaut, sous SELinux la plupart des objets sont défini à s0 uniquement, ce qui veut dire que les paramètres MLS/MCS ne sont pas appliqués.

Interprétons le résultat de la commande semanage login -l :

Login Name                SELinux User              MLS/MCS Range

__default__               user_u                    s0
root                      sysadm_u                  s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

Ci-dessus, on peut constater que l'utilisateur user_u peut accéder uniquement à des données de sensibilité 0 d'aucune catégorie. sysadm_u peut accéder à des données de sensibilité 0 mais aux catégories de fichiers allant de 0 à 1023.

SELinux prévoit un contexte d'utilisation des ports réseau. Selon SELinux, le service HTTP est prévu uniquement pour fonctionner sur les ports 80, 443, 488, 8008, 8009, 8443. Si le service HTTP est mappé sur un autre port, SE Linux en empêchera l'accès.

Pour lister le confinement des ports dans les services :

semanage port -l

Pour confiner le port 81 au service HTTP :

semanage port -a -t http_port_t -p tcp 81

Pour le supprimer :

semanage port -d -t http_port_t -p tcp 81

Pour lister les contextes par défaut des fichiers, programmes et répertoires :

semanage fcontext -l

Pour vérifier que contexte que devrait avoir un fichier, répertoire… (toujours préciser le chemin absolu) :

matchpathcon /var/www/file.html

Pour restaurer le contexte des fichiers se trouvant dans /var/www (toujours préciser le chemin absolu) :

restorecon -v /var/www/*

Si on prévoit un nouveau répertoire pour les fichiers html d'apache, il faut définir le contexte par défaut de ce nouveau répertoire (/var/www2) (Il est utile de connaître les expressions rationelles):

semanage fcontext -a -t httpd_sys_content_t '/var/www2(/.*)?'

En effet lorsque l'on crée un répertoire /var/www2 le répertoire par défaut prend le contexte de /var (system_u:object_r:var_t:s0).

A des fins de tests, on peut également utiliser la commande chcon, mais attention un contexte changé avec cette commande risque tôt ou tard d'être remplacé par le contexte par défaut (commande restorecon ou la planification autorelabel). La syntaxe de chcon est la suivante :

chcon staff_u:object_r:staff_xauth_home_t:s0 /home/staff/.Xauthority

Pour restaurer les labels des fichiers lancer :

touch /.autorelabel
reboot

Auditer les règles permet de régler un certain nombre le problèmes d'accès lié à SELinux.

Installer l'outil d'audit :

apt-get install auditd

Une fois auditd installé et démarré les logs liés au problèmes d'accès de SE Linux seront disponibles dans /var/log/audit/audit.log

La commande suivante permet de lister toutes les interdictions et de donner les suggestions :

audit2why -la

La commande suivante permet de gérer des règles d'autorisation SELinux à partir des interdictions :

audit2allow -lar

Attention Avant d'avoir recours à cette procédure vérifiez bien que les blocages ne soient pas liés à des problèmes de contexte sur les fichiers.

Points à savoir : Le module local est un module dédié à la personnalisation des règles SE Linux. Lorsque vous avez recours à l'utilisation de ce module, conservez un historique et maintenez bien le fichier local.te

Pour créer des modules de règles à partir des interdictions suivre les instructions suivantes :

mkdir -p /etc/selinux/default/src/policy && cd /etc/selinux/default/src/policy
semodule -R
cat /var/log/audit/audit.log |audit2allow -l -m local >> local.te
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -i local.pp
semodule -l
sesearch --allow

Description des actions réalisées ci-dessus :

1. On crée un répertoire pour stocker nos fichiers sources SELinux et on se positionne dedans
2. On recharge les modules SE Linux… Il faut attendre quelques minutes, voir quelques heures, pour laisser l'audit relever des interdictions.
3. On affiche les logs /var/log/audit/audit.log et on génère un fichier de description des nouvelles règles à partir des interdictions relevées depuis le dernier rechargement des modules SE Linux.
4. On compile le fichier local.te pour en faire un module
5. On crée le paquetage SELinux local.pp
6. On installe le paquetage SELinux local.pp
7. On vérifie que le module local est bien chargé
8. On analyse si nos nouvelles règles sont bien intégrées

Attention Vérifiez bien le contenu de local.te et modifiez le manuellement si besoin, car il se peut que vous ne vouliez pas autoriser certaines règles.

Exemple d'un fichier local.te :

module local 1.0;

require {
      type semanage_t;
      type postfix_pickup_t;
      type httpd_sys_content_t;
      type crond_t;
      type selinux_config_t;
      class capability sys_chroot;
      class dir { rename search };
}

#============= crond_t ==============
allow crond_t httpd_sys_content_t:dir search;

#============= postfix_pickup_t ==============
allow postfix_pickup_t self:capability sys_chroot;

#============= semanage_t ==============
allow semanage_t selinux_config_t:dir rename;

On peut distinguer 3 parties dans le fichier :

• l'entête
• Les pré-requis
• Les règles

Entête : L'entête doit comporter le nom valide du module local et la version : module local 1.0;

Pré-requis : Il faut déclarer les type et les class nécessaires à la création du module :

• type prérequis : httpd_sys_content_t, postfix_pickup_t, crond_t, semanage_t, selinux_config_t et qu'il faut un certain nombre de class.
• class pré-requises : capability sys_chroot, dir { rename search };

Règles : Définir les autorisations. Si les types et class ne sont pas déclarés dans les prérequis, les règles ne pourront pas être créées:

• allow crond_t httpd_sys_content_t:dir search;
• allow postfix_pickup_t self:capability sys_chroot;
• allow semanage_t selinux_config_t:dir rename;

Pour beaucoup de cas communs, il est possible d'activer des droits particuliers à l'aide de booléens. Les booléens sont des paramètres que l'on peut activer ou désactiver selon l'utilisation particulière qu'on fait des services protégés.

Pour lister les autorisations particulières qui peuvent être autorisées lancer l'une des commandes suivantes :

getsebool -a
semanage boolean -l

SE Linux ne permet pas pardéfaut à un utilisateur sysadm_u de se connecter directement en SSH. Pour que SE Linux permette cette action :

setsebool ssh_sysadm_login on

Vous ne pourrez plus redémarrer les services avec par la commande du type : /etc/init.d/ssh restart puisque seul initrc_t est habilité lancer un script rc. Pour redémarrer un service il faut dorénavant lancer :

run_init etc/init.d/ssh restart

Vous ne bénéficierez plus de tous les privilèges de root si vous faite un su -. Définissez un utilisateur de confiance autorisé à faire un su, et mappez celui-ci à l'utilisateur SELinux sysadm_u. Lancez l'une des commandes suivantes :

semanage login -a -s sysadm_u benoit
semanage login -m -s sysadm_u benoit

Pensez à basculer en permissive si vous êtes bloqué :

setenforce 0

Cette section concerne les programmeurs qui développe une nouvelle application sous GNU/Linux et qui souhaite la sécuriser avec SE Linux. Installer les sources des règles de SELinux :

apt-get install selinux-policy-src

Décompresser les sources :

cd /usr/src/
tar xzvf selinux-policy-src.tar.gz

Quelques exemple de fichiers de configurations dans /usr/src/selinux-policy-src/doc

A suivre…

Ci-dessous, tous les articles et tutoriels qui m'ont aidé à créer cette page sur SELinux :

• Voici un article où le concept de SE Linux est très bien expliqué : http://www.linuxcertif.com/doc/Comprendre%20SELinux/
• Documentation de SE Linux sous RedHat : manage-selinux-rhel5.pdf
• Quelques conseils pratiques : http://doc.fedora-fr.org/wiki/SELinux
• Documentation pour créer ses propre règle : http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html
• http://www.profdinfo.com/web/420-128-LG/Section%205.html
• http://www.supinfo-projects.com/en/2005/selinux_2005/introduction/