Modification rapide d'une politique SELinux

Rédigé par Nicolas Sulek Aucun commentaire
Classé dans : Système Mots clés : CentOS, SELInux
Les politiques targeted et strict de SELinux peuvent avoir des bugs ou ne pas couvrir tous les cas, surtout lorsqu'il s'agit de logiciels provenant de dépôts tiers ou sous forme d'archives tar.gz ou tar.bz2.
Voici une manière de les compléter rapidement et, surtout facilement.

Récupération des erreurs SELinux


Le paquet audit contient les outils en espace utilisateur permettant de stocker et d'exploiter les messages générés par le sous-système audit du noyau Linux.
Le Linux Auditing System Daemon, auditd de son petit nom, permet de collecter tous les événements liés à la sécurité dans un journal de log dédié (/var/log/audit/audit.log). S'il est désactivé, les événements sont envoyés directement à syslog qui les stockera dans /var/log/messages.
Il vaut mieux l'activer afin d'isoler les messages d'erreur SELinux dans un fichier séparé, qui sera nettement plus pratique à consulter.

Pour l'installation, rien de compliqué, il suffit d'un simple
yum install audit

On l'active au démarrage avec
chkconfig auditd on

et on le démarre immédiatement avec
service auditd start

La partie collecte des événements de SELinux est terminée.

Traitement des erreurs


Les erreurs SELinux sont trouvables dans /var/log/audit.log en cherchant les avc denied (Access Vector Cache denied) :
grep "avc: denied" /var/log/audit/audit.log

Par exemple :
 type=AVC msg=audit(1341257191.023:259): avc:  denied { append } for pid=1989 comm="psad" name="hosts.deny" dev=sda2 ino=1199 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file

Ici, le processus psad n'a pas le droit d'ajouter de texte au fichier /etc/hosts.deny
Ainsi, il suffit de faire fonctionner le logiciel problématique pour générer les erreurs SELinux qui seront enregistrées dans /var/log/audit/audit.log.
Une fois ces erreurs stockées, il faut créer un module SELinux autorisant ces accès refusés à l'aide audit2allow présent dans le paquet policycoreutils-python.

Pour commencer, on va créer un fichier mypsad.te qui va lister tous les nouveaux droits qui seront attribués à psad :
grep psad /var/log/audit/audit.log | audit2allow -m mypsad > mypsad.te

Le fichier résultat :
module mypsad 1.0;

require {
type tmp_t;
type net_conf_t;
type psad_t;
type iptables_tmp_t;
type psad_exec_t;
type etc_t;
type unconfined_exec_t;
class dir { write add_name };
class file { write getattr append create execute_no_trans };
}

#============= psad_t ==============

allow psad_t etc_t:dir { write add_name };
allow psad_t etc_t:file create;

allow psad_t iptables_tmp_t:file { write getattr };

allow psad_t net_conf_t:file append;

allow psad_t psad_exec_t:file { write execute_no_trans };

allow psad_t tmp_t:file { write getattr };

allow psad_t unconfined_exec_t:file { write getattr };

On remarque que psad aura notamment le droit d'écriture dans /etc, ce qui correspond bien à l'erreur citée précédemment. Il ne reste plus qu'à créer le module pour l'activer dans SELinux.

Par exemple, pour psad :
grep psad /var/log/audit/audit.log | audit2allow -M mypsad

On récupére un module binaire mypsad.pp qu'il faut ensuite installer à l'aide de semodule présent dans le paquet policycoreutils :
 semodule -i mypsad.pp

Le module est alors installé et activé, autorisant de manière permanente les accès précédemment refusés. Ainsi, il a été copié dans /etc/selinux/targeted/modules/active/modules dans le cas de la politique targeted de SELinux.
On peut également vérifier qu'il est bien activé avec semodule -l

Les commentaires sont fermés.

Fil RSS des commentaires de cet article