module bugzilla 1.0; require { type postgresql_port_t; type net_conf_t; type httpd_bugzilla_script_t; type tmp_t; type http_port_t; class tcp_socket { name_connect setopt read create ioctl write getattr connect getopt }; class dir { write remove_name getattr search add_name }; class udp_socket { write read create connect getattr }; class file { write getattr read create unlink ioctl }; } allow httpd_bugzilla_script_t http_port_t:tcp_socket name_connect; allow httpd_bugzilla_script_t net_conf_t:file { read getattr }; allow httpd_bugzilla_script_t postgresql_port_t:tcp_socket name_connect; allow httpd_bugzilla_script_t self:tcp_socket { setopt read create getattr write ioctl connect getopt }; allow httpd_bugzilla_script_t self:udp_socket { write read create connect getattr }; allow httpd_bugzilla_script_t tmp_t:dir { write remove_name getattr search add_name }; allow httpd_bugzilla_script_t tmp_t:file { write getattr read create unlink ioctl };C'est relavitement claire. Et on n'autorise que ce qui a été refusé. Un spécialise sécurité ou Bugzilla ferait mieux. Par exemple en refusant toujours certaines actions qui ne sont pas indispensables à Bugzilla. Mais on est "seulement" un utilisateur lambda qui veut se débarasser d'un problème. Le fichier bugzilla_avc.txt sera plus "précis" (il donne les répertoires ou fichiers par exemple et non seulement les domaine). Mais oublions ces détails. Le module créé, n'est pas actif. Pour l'activer c'est simple : `# semodule -i bugzilla.pp` C'est assez long (10 ou 20 secondes). Une grosse partie est faite en python. Et voilà :-) Évidemment celui qui voudra faire ça devra faire quelques man, etc... Mais c'est à la portée de beaucoup. Ça m'a pris une demi-journée. Ça a été le seul momemt que j'ai consacré à SeLinux alors que mes bécane ont SeLinux activé depuis 2 ans en gros. On peut déjà entre voir des possibilités d'"apprentissage". Mais généraliser l'"apprentissage n'est pas un bonne solution (j'en parle plus loins). Notez bien que ceci peut être fait sans désactiver SeLinux ni le passer en mode permissif ! Si on n'est pas on mode permissif, il peut être nécessaire (et c'est très probable) de réitérer les opérations précédentes (en complétant bugzilla_avc.txt) jusqu'à ce que SeLinux ne dise plus rien. Ça peut être assez long, mais ça marche. C'est le prix à payer pour ne pas "baisser la garde" (c-à-d passer SeLinux en mode permissif). On a réglé notre problème bloquant, mais d'un point de vu global ce n'est pas satisfaisant. Ça ne va pas rendre Linux (le système d'exploitation installé sur des millions de bécane) plus sûr. Si tout le monde ne fait que ça, autant virer SeLinux. On comprend ici pourquoi je suis contre la généralisation de l'"apprentissage". Mais c'est là qu'il faut garder à l'esprit comment sont développer les "vraies" règles SeLinux ("vraies" en opposition aux règles qu'on vient de créer à l'arraché). Les "vraies" règles sont celles fournies par SeLinux (NSA) ou Red Hat/Fedora, ou autres mais des spécialistes en sécurité. Donc une fois mon problème bloquant réglé, j'ai fait un rapport de bug sur le paquet selinux-policy-targeted. J'y ai joint bugzilla_avc.txt (et bugzilla.te, mais il peut être généré depuis bugzilla_avc.txt donc c'est sans grand intérêt). Maintenant des spécialistes sécurités vont analyser le problème, peut-être contecter les développeurs de Bugzilla s'ils voient des choses étranges et une prochaine version de selinux-policy-targeted prendra en charge sans accro Bugzilla. Et nous on va pouvoir se débarraser de notre module de misère qu'on a créé "à l'arrache" (on vire le module avec `semodule --remove=bugzilla`). Il faut bien retenir ici, que ce n'est pas aux développeurs de Bugzilla de créer des "vraies" règles SeLinux. Ni à nous (pauvre utilisateur lambda ou administrateur qui n'a pas que ça à foutre). Mais aux spécialistes sécurité/selinux. Donc la complexité du coeur de SeLinux nous concerne peu (on l'a vu) et elle concerne peu les développeurs. C'est l'affaire de spécialistes. On a ainsi le bon outil pour répondre aux problèmes de sécurité (par exemple SeLinux :-)). Par un outil qui a été dégradé afin facilité la vie des apprenties sécurités. J'ai titré le journal "Le nouveau SeLinux". Alors il y a quoi de nouveau par rapport à l'époque de FC2/FC3. Il y a les booléens. On peut les voir/utiliser avec getsebool/setsebool ou avec system-config-selinux (interface graphique). Par exemple le booléen httpd_use_nfs (permet à apache de lire écrire sur une partition NFS). Le booléen allow_mplayer_execstack pour que mplayer puisse utiliser certains codec mal codés ou pour charger des dll windows. Pour F8 il y en a 112. Ils sont classés dans une quinzaine de catégorie (Samba, httpd, ftp, etc). Le paquet selinux-policy à entre autre la doc relative à ces booléens. Dans les nouveautés, Il y a les modules. Ça permet de changer la configuration de SeLinux à la volée sans tout casser et facilement. Ça permettra aussi de fournir des régles de sécurités très spécifiques qui ne seront pas développées par la NSA par exemple. Règles dédiées à une applie et règles qui pourront être auditées par des spécialites afin de vérifier si tout et n'importe n'est pas autorisé. Il y a des outils (dont certains graphiques) pour faciliter la vie des utilisateurs. On l'a vu dans ce journal. Il y a les règles "targeted" de Fedora qui ne sont plus targeted mais bien aujourd'hui des règles strict (Fedora ne fournit plus selinux-policy-strict). D'ailleurs, contrairement au début de selinux-policy-targeted, il n'est plus possible de désactiver SeLinux pour un service. C'est-à-dire que Fedora a débuté avec un jeux de règles qui concernait un nombre limité de service (apache, etc) et qu'on pouvait désactiver car elles étaient peu souples (pas de booléen par exemple), à des règles qui maintenant contrôlent une bonne partie du système (jusqu'à des applis utilisateur, firefox ou mplayer par exemple). Contrôle qui comme on l'a vu peut-être inhibé très localement si c'est nécessaire (pour un besoin particulier ou à cause d'un bug dans les règles). Enfin SeLinux peut maintenant circuler sur le réseau. Par exemple le boss sera dans la catégorie boss_t et il y a que lui qui pourra se connecter à [ftp://ftp.topsecret.com/](ftp://ftp.topsecret.com/) . Et encore plein d'autres choses. L'avenir de Selinux ? Je crois que SeLinux a maintenant un bon niveau de maturité et est définitivement sortit du laboratoire. C'est le top de la sécurité actuellement. Les choses vont être paufinées, son usage sera plus accessible (via des applis graphiques par exemple) sans faire le moindre compromis sur la sécurité. Je pense que petit à petit d'autres distributions vont y venir. Ça ne sera pas rapide. Ici je pourrais glissé sur LSM qui complique grandement le développement de SeLinux (en fait de tout le monde) et AppArmor qui impose LSM car AppArmor est populaire. Mais je vais éviter. Zut, trop tard. En passant, un document très honnète sur les fonctionnalité de AppArmor, c'est écrit par AppArmor ! : [http://kerneltrap.org/Linux/AppArmors_Security_Goals](http://kerneltrap.org/Linux/AppArmors_Security_Goals) C'est surtout Novell qui dit n'importe quoi et surtout lorsque Novell fait une comparaison de AppArmor avec SeLinux. M'enfin, je parie que Novell (peut-être pas OpenSuse) va revenir à SeLinux.