Movim: Essai d’installation

Dernièrement, j’ai décidé de voir ce que propose les réseaux sociaux alternatifs libres. Ayant eu l’occasion d’assister à une conférence sur Movim et de d’échanger rapidement avec son concepteur, je me suis donc décidé à tenter l’installation complète. Pour cela, j’ai choisi le serveur xmpp Prosody, qui embarque un serveur Bosh nécessaire pour traduire les requêtes entre les protocoles http et xmpp. Nous allons donc commencer par là.

Prosody

L’installation s’effectue via le gestionnaire de paquets (ici, aptitude) :

aptitude install prosody

Une fois Prosody installé, on se tourne vers la configuration de la bête en modifiant le fichier /etc/prosody/prosody.cfg.lua. Les modifications intéressantes sont les suivantes, à adapté selon vos besoins bien sûr.

"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
allow_registration = false;

VirtualHost "domain.com"
        enabled = true

cross_domain_bosh = true

Le mode d’authentification doit rester en internal_plain, le changer empêche de se logger correctement. Nous pouvons dès à présent redémarrer le service pour que la configuration soit appliquer :

service prosody restart

A présent, ajoutons un utilisateur :

prosodyctl adduser user@domain.com

Pour supprimer un utilisateur si besoin :

prosodyctl deluser user@domain.com

Les comptes utilisateurs relatifs aux différents domaines sont stockés dans /var/lib/prosody/. Voilà pour la partie relative à Prosody, à ce stade, il est normalement possible de se connecter à un salon de discussion xmpp en utilisant l’utilisateur ajouté tout à l’heure.

Movim

Nous passons ensuite à l’installation de Movim à proprement parler. J’ai d’abord essayer de récupérer directement les sources à partir de la branche master, mais un fichier de dépendance était manquant et empêchait le fonctionnement de l’application. Je me suis donc tourné vers la version 7.2.

On change ensuite le propriétaire de l’arborescence  du dossier movim pour que celui-ci soit utilisable par Apache.

chown -R www-data:www-data movim

Il est maintenant temps de modifier la configuration de movim, soit le fichier movim/config/conf.php, et notamment les champs suivants :

'environment' => 'production',
'dbType' => 'mysql',
'dbUsername' => 'movim',
'dbPassword' => 'password',
'dbHost' => 'localhost',
'dbPort' => '3306',
'dbName' => 'movim',
'boshUrl' => 'http://domain.com:5280/http-bind',

On aura bien entendu pris soin de créer au préalable l’utilisateur et la base de donnée MySQL qui convient.

mysql -p -u root
  mysql> CREATE DATABASE movim;
  mysql> GRANT ALL PRIVILEGES ON `movim`.* TO 'movim'@'localhost' \
    IDENTIFIED BY 'password';

Apache

Pour rendre tout cela accessible, il nous faut maintenant configurer Apache. Soit le fichier movim dans /etc/apache2/sites-available/.

<VirtualHost *:80>
      ServerAdmin webmaster@localhost
      ServerName movim.domain.com
      DocumentRoot /var/www/movim
      <Directory />
              Options FollowSymLinks
              AllowOverride None
      </Directory>
      <Directory /var/www/movim>
              Options Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              allow from ALL
      </Directory>
</VirtualHost>

Puis les commandes habituelles :

a2ensite movim
service apache2 restart

Suite et fin

Movim est désormais accessible sur movim.domain.com. Un petit tour dans l’interface d’admin du nœud est nécessaire pour s’assurer que tout fonctionne correctement et initialiser la base de donnée. Les identifiants de connexion sont ceux configurés dans le fichier de configuration de movim.

Résultat, nous pouvons nous connecter à notre nœud movim grâce au compte xmpp que nous avons créé précédemment. L’ensemble est bien vide, puisque nous sommes seuls sur le nœud. En essayant diverses fonctionnalités, j’obtiens de temps à autre des messages d’erreur sur la gauche de mon écran. Comme je n’utilise pas la dernière version, je n’ai pas vraiment creusé pour savoir si cela provient de movim ou de mon serveur Prosody. J’arrive par contre à faire communiquer deux utilisateurs entre eux via le chat intégré.

Bilan mitigé, « I have mixed feelings » comme disent les anglais. Movim a un potentiel certain, néanmoins, l’installation de sa propre instance complète Movim et serveur xmpp n’est pas de tout repos. La procédure d’installation est très limitée en ce qui concerne la partie xmpp. J’avais pourtant le souvenir d’une documentation beaucoup plus complète des différentes solutions disponibles lors de mon premier passage sur le wiki il y a de cela plusieurs mois. Je partage donc les quelques étapes que j’ai suivi pour l’installation de Movim. L’ensemble est plus ou moins complet et pourrait servir de base à toute personne cherchant à tester l’application.

Limiter la RAM disponible pour Mongo

Pour des besoins de test, et notamment dans le but de mesurer les performances et d’analyser le comportement de Mongo avec différentes quantités de mémoire vive, je me suis penché sur la façon de restreindre les ressources pour un processus donné sous GNU/Linux.

Je me suis d’abord tourné vers ulimit qui semblait permettre de restreindre explicitement la ram, avec en particulier la commande suivante:

ulimit -Hm 30000

Pour la mémoire virtuel, on remplace le m par un v, par exemple:

ulimit -Sv 200000

Cette façon de faire n’était malheureusement pas satisfaisante. En surveillant mon mongo avec mongostat, je constate que celui-ci dépasse largement les limites imposées. Je me tourne donc vers une autre solution: les cgroups.

Reprenons la définition de Wikipédia, les cgroups sont une fonctionnalité du noyau Linux permettant de « limiter, compter et isoler l’utilisation des ressources ». Ça tombe bien, c’est exactement ce que je cherche à faire. En bonus, les cgroups sont utilisés par les LinuX Containers (LXC), procédé de « virtualisation légère », une raison de plus de s’y intéresser.

Revenons à notre problématique de limitation de la ram de mongo. Dans un premier temps, il est nécessaire de préparer l’environnement:

aptitude install libcgroup1

Si le paquet n’est pas disponible sous ce nom là, une simple recherche de cgroup devrait permettre de le trouver. Nous allons tout d’abord créer un nouveau cgroup qui nous permettra d’appliquer les limitations:

sudo cgcreate -t <user> -a <user> -g memory,cpu:<groupname>

Ici, notre cgroup pourra imposer des limites sur la mémoire (memory) et le processeur (cpu).  Nous pouvons maintenant définir les paramètres de notre groupe, en terme de mémoire notamment:

echo 33000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes

Ici, nous limitons la mémoire vive à 33 Mo pour notre cgroup. Des raccourcis existent pour l’écriture des quantités d’octets, on pourrait par exemple remplacer 33000000 par 33M. Il ne nous reste plus qu’à démarrer notre processus mongo avec ces restrictions:

cgexec -g memory:<groupname> mongod

En surveillant notre mongo avec mongostat, nous pouvons ainsi constater une augmentation du nombre de « page faults » lorsque nous réduisons la mémoire disponible de manière significative et constater que mongo prend bien en compte la limite.

Voilà donc un court exemple qui permet d’éviter de saturer sa ram en totalité avant de pouvoir commencer des tests sur mongo, notamment en ce qui concerne l’étude du nombre de « page faults » en fonction du working set et de la ram disponible. Ce procédé peut bien sûr être appliquer à d’autres processus pour éviter qu’ils ne consomment toutes les ressources de la machine. Pour de plus amples d’informations sur le sujet, on se tournera vers le wiki Arch Linux ou encore ce guide Red Hat.

All your password are belong to us

Ou pourquoi un mot de passe se doit d’avoir une taille minimum et d’éviter de suivre un motif particulier.

Comme vous le savez certainement, il n’est pas toujours aisé, pour un hacker ayant découvert une faille de sécurité dans un système informatique, de contacter les responsables du système pour le leur signaler. Certaines entreprises, la première me venant à l’esprit étant Google, prennent facilement en compte les alertes (il me semble). Dans d’autres cas, le simple fait de signaler la faille vous assimile à un pirate…

Sur cette petite introduction, je vais maintenant revenir sur une situation à laquelle j’ai été confronté. Pas de faille de sécurité à proprement parler, mais un constat sur la politique de création et d’utilisation des mots de passe d’une plate-forme. Penchons-nous donc sur le problème.

La plate-forme en question n’héberge pas de données personnelles sensibles à proprement parler, pas de numéro de carte de crédit, pas d’adresse. Elle propose néanmoins un compte pour l’utilisateur qui contient donc un minimum d’informations le concernant: ses noms et prénoms notamment. Venons en au sujet qui fâche: le mot de passe d’accès à l’espace utilisateur. Premièrement, il n’est pas possible de le modifier via l’interface. Deuxièmement, et c’est là que certains des lecteurs vont commencer à s’étrangler. Le mot de passe n’est composé que de 5 caractères.

Regardons le nombre de mot de passe différents qu’il est possible d’obtenir si on considère que le mot de passe est généré avec au choix:
* les lettres de l’alphabet latin en minuscule ou en majuscule (52 possibilités).
* les chiffres (10 possibilités).
* les caractères spéciaux comme @ / [ {  (34 possibilités environ).
En résumé, pour chaque caractère: 52 + 10 + 34 = 96 possibilités.
Ce qui nous donne donc 96 *96 *96 *96 *96 = 96^5 = 8 153 726 976, un peu plus de 8 milliard de mot de passe différents. C’est peu mais ça reste beaucoup plus élevé que le nombre qui va suivre.

En effet, le massacre n’est pas fini… les mots de passe suivent un motif particulier. Ils sont constitués de l’année de naissance de l’utilisateur avec la première lettre de son nom. En résumé, une lettre et un nombre à 4 chiffres, 10 * 10 * 10 * 10 * 26 soit 260 000 possibilités. Nous sommes loin des 8 milliard initiaux et ça commence à faire peur.

Ce nombre peut encore être réduit, puisqu’on parle d’année de naissance. En considérant un intervalle simple d’une centaine d’année, on est presque sûr d’englober tous les cas possible, à l’exception des personnes plus que centenaire. En définitive, on se retrouve avec grand maximum 100 * 26 = 2 600 mots de passe différents ce qui est tout simplement ridicule.

Alors évidemment, on pourrait me faire remarquer qu’il faudrait connaître l’identifiant du compte pour que cela deviennent dangereux. Effectivement, et dans notre cas, oh malheur! L’identifiant est un nombre à 9 chiffres. A mon sens, la sécurité est insuffisante sur cette plate-forme, à cause d’une politique de génération des mots de passe défectueuse.

Imaginons un instant que l’on puisse tester un mot de passe par seconde… Vous voyez où je veux en venir n’est-ce pas? En moins d’une heure, toutes les possibilités pourraient être essayer. Cela prendrait seulement 43 minutes et 20 secondes pour être précis.

Si j’écris tout cela, c’est pour tenter de montrer combien un mot de passe qui suit un même motif pour tous les utilisateurs est un mauvaise chose et encore plus lorsque la génération se base sur des données personnelles comme la date de naissance. Je peux comprendre une partie des choix qui ont pu mener à une telle situation: facilité de mémorisation pour les utilisateurs, inutilité d’un système de récupération de mot de passe puisque le motif est connu de tous, place réduite en base de donnée. Quand bien même, tous ces arguments me semblent insuffisants pour justifier une telle politique de sécurité, d’autant plus lorsqu’on manipule un minimum de données personnelles.

Bloc-note dans le navigateur

Une petite astuce trouvé sur le net pour disposer d’un bloc-note dans le navigateur en utilisant simplement du html. Il suffit d’utiliser le code suivant dans la barre d’adresse du navigateur:

data:text/html, <html contenteditable>

Un petit marque-page et le tour est joué.

J’utilise personnellement une version légèrement personnalisée avec texte blanc sur fond noir:

data:text/html, <html contenteditable style="color:white; background-color:black">