Depuis que je suis passé à SELinux sur une Gentoo, beaucoup de problèmes sont apparus. Afin d’avoir un système un minimum utilisable, j’ai passé SELinux en mode permissive, malgré tout, cela ne résout pas tout, notamment des crons utilisateurs qui ne se lancent plus.
Précisons tout d’abord que mon système de cron est vixie-cron, qui semble être le daemon préféré sous Gentoo.
J’ai eu très peu d’informations au début lorsque j’ai voulu trouver pourquoi les crons ne se lançaient plus, que ce soit dans /var/log/kern.log où se trouve les logs de SELinux, ou dans /var/log/syslog. Je savais que ça provenait de SELinux puisque côté ACL, tout était nickel, et puis ça marchait très bien avant. La seule trace concrète du problème apparaît lorsqu’on redémarre le daemon vixie ; on peut lire ceci dans les logs :
root@stormrage:[~] # zgrep ENTRYPOINT /var/log/syslog-20120318.gz Mar 17 20:42:01 stormrage cron[2943]: (munin) ENTRYPOINT FAILED (crontabs/munin) Mar 17 20:42:01 stormrage cron[2943]: (anakin) ENTRYPOINT FAILED (crontabs/anakin)
Voyons les permissions SELinux sur les user-crons :
root@stormrage:[~] # ls -lZ /var/spool/cron/crontabs/ total 12 -rw-------. 1 anakin crontab anakin:object_r:user_cron_spool_t 274 6 nov. 13:54 anakin -rw-------. 1 munin crontab munin:object_r:user_cron_spool_t 1180 9 janv. 17:31 munin -rw-------. 1 root crontab root:object_r:user_cron_spool_t 657 17 mars 20:41 root
Je suis encore relativement novice à SELinux, mais il est clair que munin et anakin ne sont pas relié explicitement à un utilisateur SELinux, du moins il faut que ce soit une action volontaire. Ainsi, en obtenant la liste des contextes valides pour l’utilisateur Linux munin depuis le contexte dans lequel le daemon s’exécute (voir la commande ci-dessous), on a un seul résultat, qui ne correspond pas au contexte actuel sur les user crontabs.
root@stormrage:[~] # ps -AfZ | grep cron system_u:system_r:crond_t root 2521 1 0 Mar17 ? 00:00:00 /usr/sbin/cron root@stormrage:[~] # getseuser munin system_u:system_r:crond_t seuser: user_u, level (null) Context 0 user_u:user_r:cronjob_t
D’où un chcon -u user_u sur tous les user crontabs et le tour est joué.
root@stormrage:[~] # ls -lZ /var/spool/cron/crontabs/ total 12 -rw-------. 1 anakin crontab user_u:object_r:user_cron_spool_t 274 6 nov. 13:54 anakin -rw-------. 1 munin crontab user_u:object_r:user_cron_spool_t 1180 9 janv. 17:31 munin -rw-------. 1 root crontab root:object_r:user_cron_spool_t 657 17 mars 20:41 root
Je ne sais pas si user_u est le bon utilisateur SELinux à appliquer, en terme de sécurité, mais au moins les crons se lancent à nouveau.
On notera cependant que restaurer les contextes par défaut avec restorecon ou rlpkg ré-appliquent des contextes invalides. De même, éditer depuis root les crontabs d’autres utilisateur avec un crontab -e applique un mauvais contexte, il semble préférable de passer par un su/sudo au préalable.
Il faudra donc penser à vérifier spécifiquement les contextes sur ces fichiers à chaque fois que le système de fichier est relabelisé.
Au final, je reste persuadé que SELinux est une bonne technologie mais elle n’est pas prêt à l’emploi (cela vaut également pour Red Hat), même en partant avec une stratégie de base comme celle fournie par Tresys. A moins de faire un serveur très bâteau, il sera certain qu’il faudra auditer et réajuster la stratégie SELinux avant de la valider pour une production.