Utiliser SELinux pour protéger un forum SMF

Un article un peu pratique : comment configurer SELinux pour protéger un forum de type SMF (simple machine forum) ? (c’est largement utilisable pour d’autres forums).

SELinux fera l’objet d’un billet spécifique donc je ne le présente pas ici.

La configuration de base

Pour être efficace, SELinux doit être en mode enforcing. De plus, comme on le verra dans un prochain billet, nous avons fait le choix d’utiliser la politique MLS.

La configuration du serveur

Nous utilisons la configuration suivante :

  • Centos 6 à jour
  • SELinux : politique MLS
  • LibSELinux-devel
  • HTTPD (apache)

En détails, les dépendances pour SELinux :

[root@ossus]# rpm -qa | grep selinux
libselinux-utils-2.0.94-7.el6.x86_64
libselinux-2.0.94-7.el6.x86_64
libselinux-devel-2.0.94-7.el6.x86_64
libselinux-python-2.0.94-7.el6.x86_64
selinux-policy-3.7.19-292.el6.noarch
selinux-policy-mls-3.7.19-292.el6.noarch
selinux-policy-targeted-3.7.19-292.el6.noarch

Avec la politique de base, nous avons donc

ps auxwZ | grep apache
system_u:system_r:httpd_t:s0-s15:c0.c1023 apache 4410 0.5 1.2 478756 49552 ? S 16:25 1:01 /usr/sbin/httpd

Le contexte d’apache est donc system_u:system_r:httpd_t:s0-s15:c0.c1023.

SMF est installé dans le répertoire /var/www/html/forum/.

La politique SELinux

Avec la politique de base de SELinux, les éléments présents dans /var/www/html ont le contexte suivant : httpd_sys_content_t

Par défaut, httpd_t n’a pas les permissions de modification (création, suppression, exécution, etc.). Pour preuve, les AVC générés par apache :

type=AVC msg=audit(1466969654.803:74508): avc: denied { add_name } for pid=29483 comm=”httpd” name=”” scontext=system_u:system_r:httpd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
type=AVC msg=audit(1466969654.880:74511): avc: denied { setattr } for pid=29483 comm=”httpd” name=”” dev=sda1 ino=1182475 scontext=system_u:system_r:httpd_t:s0-s15:c0.c1023 tcontext=staff_u:object_r:httpd_sys_content_t:s0 tclass=file
type=AVC msg=audit(1466969656.954:74512): avc: denied { remove_name } for pid=29483 comm=”httpd” name=”” dev=sda1 ino=1702698 scontext=system_u:system_r:httpd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
type=AVC msg=audit(1467154855.120:80140): avc: denied { write } for pid=5473 comm=”httpd” name=”” dev=sda1 ino=1182554 scontext=system_u:system_r:httpd_t:s0-s15:c0.c1023 tcontext=staff_u:object_r:httpd_sys_content_t:s0 tclass=file

Donc par défaut, apache n’a pas la possibilité de modifier les répertoires présents dans le sous-répertoire du forum (ni les fichiers par extension).

Le problème c’est qu’il est nécessaire pour apache de pouvoir écrire dans certains répertoires comme celui du cache, des fichiers joints, avatar, etc.

Première méthode

On autorise tout : d’un point de vu sécurité, c’est pas top top. Il suffit de faire une règle

allow httpd_t httpd_sys_content_t:dir *;
allow httpd_t httpd_sys_content_t:dir *;

et on est tranquille.

Deuxième méthode

On fait ça proprement.

File context

Création du file_context spécifique :

var/www/html/forum/attachments system_u:object_r:http_wr_smf:s0
/var/www/html/forum/attachments/*.* system_u:object_r:http_wr_smf:s0

/var/www/html/forum/avatars system_u:object_r:http_wr_smf:s0
/var/www/html/forum/avatars/*.* system_u:object_r:http_wr_smf:s0

/var/www/html/forum/cache system_u:object_r:http_wr_smf:s0
/var/www/html/forum/cache/*.* system_u:object_r:http_wr_smf:s0

/var/www/html/forum/Packages system_u:object_r:http_wr_smf:s0
/var/www/html/forum/Packages/*.* system_u:object_r:http_wr_smf:s0

/var/www/html/forum/Settings.php system_u:object_r:http_wr_smf:s0
/var/www/html/forum/Settings_bak.php system_u:object_r:http_wr_smf:s0
/var/www/html/forum/Sources/Load.php system_u:object_r:http_wr_smf:s0

Quelques explications :

  • attachments : contient les pièces jointes mises sur le forum
  • avatars : explicite
  • cache : cache du forum
  • Packages : contient les archives pour installer des modules/mises à jour du forum
  • Settings.php : pour pouvoir modifier les configurations depuis le serveur
  • Load.php : coeur du forum

Tous ces fichiers ayant (presque) les mêmes demandent de permissions, on va leur créer un type spécifique http_wr_smf On pourrait affiner un peu en créant un contexte spécifique pour chaque catégories,, mais dans un soucis de clarté, on va rester simple.

Règle SELinux

Il reste maintenant à donner l’autorisation à apache de réaliser des actions spécifiques sur ce type.
On créé le nouveau type :

type http_wr_smf

Puis on fait les règles qui vont bien :

allow httpd_t http_wr_smf:file { read write create setattr getattr unlink open rename lock} ;
allow httpd_t http_wr_smf:dir *;

allow httpd_t http_wr_smf:filesystem { associate };
allow http_wr_smf fs_t:filesystem { associate };

On compile (j’ai volontairement omis les types requis à la compilation). On charge la nouvelle politique et on applique les nouveaux contextes de sécurité, soit en utilisant restorecon soit autorelabel.

On a donc un forum fonctionnel avec SELinux en enforcing.

Retour sur armadito antivirus

Depuis maintenant quelques jours, bon nombre de personnes critiquent/jugent un projet qui est arrivé sur GitHub et qui se nomme Armadito Antivirus. Ce projet est porté par la société Teclib’.

Avant toute polémique, le but de ce billet n’est pas de savoir si ces sources sont issues ou non du projet DAVFI. Pour ceux qui ne comprennent pas, je vous laisserai chercher avec votre moteur de recherche préféré pourquoi j’écris ça. Non, ici le but est de s’interroger sur la pertinence ou pas de ce projet, pertinence scientifique bien sûr.

Qu’est-ce que Armadito Antivirus ? Pour le savoir, allons voir ce qui est dit sur le site (extrait au 9/07/2016) :

Armadito Antivirus is an open-source antivirus that protects your computers and servers from malware and viruses.

Armadito includes classical signature-based malware detection and provides innovative heuristic detection modules for binaries (MS-Windows and GNU/Linux) and for PDF documents.

An intuitive and user-friendly interface gives access to all Armadito’s features: on-demand scanning, real-time protection, quarantine zone, threat detection journal…

Armadito is remotely manageable for enterprises and organisations using a central administration console.

Un projet open-source, qui semble être développé par une entreprise française, en voila deux bons points.

Est-ce une réelle bonne idée ?

Un projet open-source ?

Premier point, et même si beaucoup de personnes pensent que non, je trouve que c’est une bonne idée. Nous avons ici un antivirus (souverain ?) dont tout le monde peut lire/vérifier/compiler les sources et se faire sa propre idée. On ne pourra pas leur reprocher de cacher des backdoors, puisque si backdoors il y a, on pourra les repérer en lisant le code source mis à notre disposition. La plupart des personnes qui râlent sur ce projet pestent aussi sur le fait que les autres projets ne publient pas leur code. Nous avons accès à tout (en tout cas pour l’instant).

Alors oui, quelqu’un qui publie son code source s’expose à ce genre de critiques : ça ne fait pas ci, il faudrait faire comme ça, etc. Mais on attend toujours la publication d’outils utiles de la part de ces mêmes personnes pour faire avancer la (recherche ?) sécurité informatique plutôt que de critiquer de manière gratuite.

Un outil pour faire la sécurité défensive

Second point, enfin un outil défensif. On trouve énormément d’outils offensifs : fuzzing, recherche de vuln, exécution d’exploits, pentest, etc. Mais peu d’outils défensifs qui font réellement de la protection. De plus, ce genre d’outil s’utilise généralement quand il est trop tard. Certes ce n’est qu’un antivirus, et il en existe pléthore, mais il a le mérite d’exister. A voir s’il sera efficace ou s’il mourra de sa belle mort tout comme Tiranium Antivirus. Je ne m’attarderai pas sur la description donnée sur le site qui vante ses qualités de détections et de protection, le mieux étant de tester pour se rendre compte de la réelle efficacité ou non d’un produit, chose que je n’ai pas encore faite.

Est-ce réellement une si bonne idée ?

On pourrait essayer de faire des paragraphes entiers à défendre le projet mais il est nécessaire de se poser la question du réel intérêt scientifique de ce (genre de) projet. Dans l’idée, les deux points positifs que je retiendrai sont le côté open-source et un outil de sécurité défensive. Mais cela ne rattrape pas ce qui va suivre.

Faire un antivirus ?

Nous sommes en 2016, l’informatique existe depuis maintenant plusieurs dizaines d’années, Internet a explosé depuis les années (19)95 et, avec, les menaces informatiques. On est passé du virus, aux spywares, aux rootkits, aux ransomware, etc. Les malware deviennent de plus en plus évolués et complexes à étudier et à supprimer d’un système. Dans ce cyber-digital-monde-de-pirate (poke Gof), la réalisation d’un antivirus montre juste le retard de l’industrie dans la protection des systèmes. On verra pourquoi dans un prochain article.

On peut noter, de plus, que le marché propose déjà un très (trop ?) grand nombre de logiciels anti-truc : antivirus, antimalware, antispyware, etc. Je ne vais pas m’amuser à tous les citer, je risquerai d’en oublier une bonne partie. Mais la multitude des outils n’a pas fait baisser la menace, ni rendu le surf plus sûr, ni éradiqué la faim dans le monde.

La plupart de ces outils sont (que je considère comme) des outils de détections. Ils ne sont pas capables d’anticiper les menaces et dès que quelque chose sort un peu de l’ordinaire (une exploitation d’une faille inconnu, un cheminement non conventionnel pour un malware), tous les outils sont dépassés. On pourrait aussi discuter des méthodes innovantes de protection pro-actives, mais il faudrait déjà comprendre ce que ça veut dire. Aucun outil n’est réellement capable de faire de la protection du système de manière efficace, c’est-à-dire bloquer un binaire avant son exécution. Un antivirus s’utilise en amont, pour protéger le système, pas pour supprimer les choses qu’il trouve, encore faut-il qu’il soit capable de le faire.

Les entreprises proposant des antivirus ou des antimalware ne sont que dans la réaction et non dans l’anticipation/la création. C’est pour cela qu’ils seront toujours derrière en matière de protection. Il n’y a que très peu de recherches (que ce soit académique ou industrielle) proposant des méthodes de protections efficaces, qui ne reposent pas sur des “choses” que l’on a déjà vu.

Donc, même si ce projet a le mérite d’exister et propose des choses, il ne va pas faire avancer la recherche ni la sécurité informatique. Ce n’est qu’un outil de plus parmi la longue liste d’outils antimachin qui ne sera pas efficace pour protéger de manière efficace un système et ces utilisateurs.

Une petite note amusante : le CERT-FR a déjà publié une note concernant une vulnérabilité dans cet antivirus CERT-FR

Nous verrons dans un prochain article les remèdes et les solutions à cela.

Un remerciement à Gof pour sa relecture.