Protection du grub : amélioration de l’interface de Mandriva

Protéger grub, pourquoi ?

Il est possible de protéger grub de l’édition en ajoutant un mot de passe. L’objectif est d’améliorer la sécurité en empêchant l’édition de grub et donc d’un accès root. Bien sûr, une telle protection est inutile si on peut démarrer sur un média externe comme une clef USB ou un lecteur optique. Un liveCD/USB permettrait de se donner un accès root. Il convient donc de protéger le bios également et de supprimer le démarrage sur média externe. Les puristes iront jusqu’à poser un cadenas sur la machine, protéger l’entrée de la salle par biométrie… bref, je m’égare.

Protéger grub, comment ?

Dans une console, on peut utiliser grub-md5-crypt :

grub-md5-crypt

Password:
Retype password:
$1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF.

Il suffit alors d'ajouter la ligne suivante
password --md5 $1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF.
dans le fichier /boot/grub/menu.lst

et c'est tout  

Et pour les anti-consoles ?

Mandriva propose bien sûr une alternative à la console pour protéger son grub. Si vous démarrez la version actuelle du centre de contrôle Mandriva et allez dans l’onglet approprié, vous verrez cette interface.

Il y a en fait trois problèmes :
Premièrement, je ne trouve pas la présentation astucieuse. Comme vous pouvez le voir, il faut aller dans "avancé" pour activer la protection dont le mot de passe se trouve dans la fenêtre principale.
Deuxièmement, la case protection se retrouve être décoché si vous revenez plus tard dans cette interface alors que la protection est active et fonctionnelle.
Troisièmement, il est impossible de désactiver la protection…

Autant de soucis méritent un patch
J’ai donc ajouté plutôt une case à cocher dans l’interface principale, case qui va (dé)griser les champs pour le mot de passe selon qu’elle est active ou non. Le fait que la case précédente était toujours décochée venait simplement d’un oubli et la désactivation de la fonctionnalité était aussi un cas oublié. Tout ceci se retrouve donc dans le patch que j’ai proposé. La nouvelle interface deviendra (si mon patch est accepté) :

Peut-on faire encore mieux ?

Je pense que oui En effet, il faut garder en tête que lorsqu’on souhaitera éditer le grub (en pressant p), il faudra entrer son mot de passe en clavier qwerty (donc en aveugle si vous avez tout autre clavier). Mon idée serait de vérifier le clavier utilisé lorsque l’utilisateur a activé la fonctionnalité et afficher un petit message informatif dans les cas nécessaires.

Mes trois derniers patches

Certains le savent, je veux m’investir au plus près du code source. Je fouine donc à travers les projets à la recherche d’une correction que je peux apporter. Mes connaissances en programmation ne sont pas encyclopédique, mais je me débrouille. Je profite de ce billet pour lancer un appel (cf partie sur Tilda)

Manque de traduction dans drakxservices (Mandriva)

Le premier patch concerne un bug que j’ai ouvert lorsque je me suis mis pour la première fois au test de distributions en développement. Ouvert fin 2008, le bug n’avait pas été corrigé, notamment à cause d’un flottement sur la personne responsable. Il était temps de prendre le taureau par les cornes et de faire un coup de perl.

Ce qui semblait à première vue un simple manque de traduction était en fait des chaines inexistantes dans les .po. Il s’avère qu’en fait, certaines chaines étaient connues et pour cause, elles apparaissent dans un hash. Mais pour les services n’apparaissant pas dans le hash, la description était directement recherché dans /etc. J’en ai donc profité pour compléter la table.

Tilda : erreur de segmentation

Un problème que j’avais remarqué sur la 2010.0, mais j’avais oublié d’ouvrir un rapport… le logiciel tilda déjà discuté  ici ne se lançait pas à cause d’une erreur de segmentation. Ce n’était pas le cas sous mandriva 2009.1 bien que la version du logiciel n’ai pas changé. Je suis parvenu à corriger l’erreur de segmentation. Si vous lisez le rapport vous verrez que j’ai supprimé l’appel à

gdk_x11_window_set_user_time ()

Selon moi, il n’y a pas d’intérêt, mais je connais très mal les API utilisé dans tilda. Si quelqu’un sait… De plus, je vais reporter le patch upstream, mais le projet semble abandonné à mon plus grand regret, j’aurai vraiment bien aimé le reprendre, mais mes compétences ne me le permettent pas encore.

Imageshack-uploader : corrections de warnings en partie dus à des changements chez ffmpeg

J’ai eu l’occasion d’aider une personne sur la mailing liste francophone d’entraide à la création de RPM pour mandriva. Le résultat se trouve là. Le patch a permis de compiler correctement le logiciel. il n’y a pas vraiment de commentaire particulier à faire si ce n’est le warning
httprequest.cpp: In member function  ‘QNetworkProxy&
HTTPRequest::getProxy()’:
httprequest.cpp:37:  attention : reference to local variable ‘p’ returned

où il manque visiblement une donnée membre du type QNetworkProxy. Je n’ai pas remonté ce point. Ce soucis de ce projet est l’organisation, il n’y a pas sur leur gestionnaire de version les codes des différentes versions. On est ainsi obligé de prendre le code sur le dépôt à moins de démanteler le .deb founit.

De la facilité à contribuer au logiciel libre

Avec cet article, je veux vous montrer en quoi il est facile de contribuer au logiciel libre, grâce à deux exemples. Le premier ne nécessite aucune connaissance en programmation puisqu’il s’agit d’un apport de traduction. Le second, quant à lui, requiert quelques connaissances en script shell, mais si peu que j’espère que cela restera compréhensible aux yeux de tous. Je donne les grandes lignes sans être exhaustif.

Manque de traduction

La traduction, encore nommée internationalisation (i18n) "localisation" (l10n), est sans doute le plus bel exemple où l’on contribue directement au coeur du logiciel mais sans aucun prérequis de programmation, tout au plus il faudra être sensibilisé à la gestion de projet libre. L’effort de traduction est tout aussi important à mes yeux que le soin apporté à la programmation. Un logiciel mal ou peu traduit fait souvent mauvaise impression et peut aller jusqu’à son abandon pour les nombreux utilisateurs non-anglophones.

L’exemple que j’ai choisi m’est venu lorsque j’ai parlé du logiciel grsync à un ami. grsync est une interface graphique GTK au puissant rsync permettant la synchronisation de répertoires. Après avoir installé la version 1.0.0 (qui s’avère être la dernière version comme l’atteste le site du projet), je vois que certaines phrases (que l’on nomme techniquement chaine de caractère) reste en anglais. Une première chose à se méfier est de penser que ce que l’on a sous les yeux est le dernier avancement du logiciel. Ce n’est bien sûr pas le cas, car des modifications du code peuvent être effectuées tous les jours sans pour autant qu’il y ait de nouvelles versions. Il faut donc aller sur le gestionnaire de version du projet afin de récupérer la version la plus avancée.

La traduction se fait, peu ou prou, de la même manière que ce que j’ai pu décrire dans cet article. Sur le SVN du projet, on ira toujours dans le tronc (trunk) et on va jusqu’au répertoire po et télécharger FR_fr.po. On modifie et on se fait un petit patch. Pour cela, je vous conseille la lecture de cette page par exemple. Je n’ai personnellement pas utilisé cette méthode, j’ai préféré git, mais on n’est pas obligé d’aller jusque là.

Voila le résultat.

Correction d’un bug logiciel

Attaquons nous maintenant à la correction d’un bug sur un logiciel. L’idée m’a été soufflée par une conférence de Parinux sur la distribution légère Slitaz. Lors d’une démonstration (c’est toujours comme ça ), le conférencier a voulu ouvrir le gestionnaire de paquet et a entré un mot de passe erroné. Après validation, rien ne s’est passé. Après une dizaine de secondes, il s’est souvenu avoir changé le mot de passe et a pu ouvrir le gestionnaire de paquet. On a là un bug manifeste, l’utilisateur aurait dû être prévenu de l’erreur sur le mot de passe. Les gens qui ont fait un peu de programmation dans leur vie sentent de suite que c’est un cas non géré, un type de bug fréquent.

L’avantage pour cette démonstration est que le site est partiellement en français car le créateur est suisse. On arrive alors sans trop de peine à la partie développement. On a remarqué que le programme portait le doux nom de subox, et une petite recherche nous montre que dans slitaz-tools/tinyutils on retrouve le code source de subox.

On récupère le code et on va donc chercher à corriger le bug. La ligne qui attire mon attention est celle-ci :

<action>echo $PASSWD | su -c "$SU_CMD" &</action>

On remarque alors qu’en cas d’échec, rien n’est prévu. Je propose donc de la remplacer par ceci :

<action> if [[ $(echo $PASSWD | su -c "$SU_CMD" &) ]]; \
then gtkdialog --center --program=ERROR_DIALOG;fi;</action>

où ERROR_DIALOG est une fenêtre qui comporte le message d’erreur. Je passe le détail de la création de cette fenêtre, tout est dans le rapport de bug, et un simple coup d’oeil sur le premier tuto gtkdialog ou la lecture d’autres scripts de la distro permet d’écrire sans problème ce morceau de code. Une fois mon fichier modifié, j’en ai crée un patch.  Le code étant petit, j’ai ajouté le programme complet en fichier attaché.

Le rapport final est disponible là, en attente d’un dev pour correction

Je n’ai pas la prétention que le patch soit idéal ou parfait. Sans doute ne respecte-il pas la politique de la distribution que je ne connais pas, mais quand bien même cela ne plairait pas aux développeurs, cela leur montrera très clairement le problème et une possibilité de résolution. Ceci accélérera dans aucun doute la résolution du bug.

Bien sûr, parfois on n’arrive pas à corriger le bug. On peut avoir qu’une piste voir rien du tout… nul n’est parfait. Dans tous les cas, il faut toujours ouvrir un rapport et indiquer les éventuelles pistes.

Conclusion

Les contributions au logiciel libre peuvent se faire sans connaissances particulières : écriture de documentations, entraide sur les canaux de communication, animations de manifestations… mais on peut avoir envie d’aller plus loin, de découvrir les rouages du moteur.

J’espère ainsi avoir montré, via ces deux exemples, en quoi il est possible de contribuer au code d’un logiciel libre soit sans connaître un langage ou soit sans être un codeur fou. Par contre, il est vrai qu’il faut être un peu familier de la gestion des projets et des outils associées (sourforge, svn, mercurial…), suffisamment pour savoir s’y repérer et récupérer un bout de code. Il existe pléthore de petits logiciels et de petits projets qui ne demandent que ce type de contribution.

Bref, si vous hésitez, même si vous pensez ne pas être à la hauteur, foncez ! Il n’y a pas de petites contributions. L’aventure est extraordinaire, on apprend plein de choses, c’est très enrichissant. En espérant vous avoir convaincu…