Copyright © 2010 Anonymous
Copyright © 2010 Luc Mioulet
Copyright © 2010 appzer0
Article paru dans le n°173 de la Gazette Linux d'avril 2010.
Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Table des matières
Tout commença avec la touche SAK (Secure Attention Key), la touche d'attention sécurisée, qui était censée résoudre mes problèmes dans Ubuntu. La seule aide que je reçue fut un kernel panic.
Il y eût ensuite les enquêtes; et après les enquêtes, vinrent les doutes. J'écris mon rapport en commençant par un récapitulatif sur SysRq, provenant principalement de http://www.kernel.org/doc/documentation/sysrq.txt Ce document ne comporte pas d'information critique, mais cette lacune est compensée dans ce document.
C'est une combinaison de touches à laquelle le kernel répondra immédiatement, quelle que soit son activité, à supposer qu'il ait été compilé avec l'option CONFIG_MAGIC_SYSRQ. C'est le cas dans la majorité des distributions GNU/LINUX.
Non, si l'on a un système compilé avec le SysRq, la touche est (généralement) activée. Cependant les distributions comme les OpenSuse ont une valeur restreinte dans /proc/sys/kernel/sysrq, ce qui veut dire que, d'après leur documentation, sysrq est désactivé par défaut. Mais on peut désactiver ou restreindre cette propriété de /proc/sys/kernel/sysrq. Par défaut ce fichier contient 1 et est pleinement activé (avec quelques exceptions; voir ci-dessus). Pour désactiver SysRq, écrivez 0 dans ce fichier.
Pour restreindre les fonctionnalités de manière sélective utilisez les valeurs de cette table :
Tableau 1. Fonctionnalités et valeurs associées
| Valeur | Option |
|---|---|
| 2 | permet le contrôle de l'enregistrement console |
| 4 | Activer le contrôle du clavier (par exemple SAK) |
| 8 | Activer l'image mémoire des processus pour le débogage |
| 16 | Activer la commande de synchronisation |
| 32 | Activer le remontage des partitions en lecture seule |
| 64 | Activer les signaux système (term,kill,oom-kill) |
| 128 | Autoriser le redémarrage/extinction |
| 256 | Autoriser le contrôle de la priorité des processus |
Choisissez vos options, faites la somme de leur valeur et écrivez la somme dans /proc/sys/kernel/sysrq; après cela, seules vos options devraient être autorisées.
La valeur de /proc/sys/kernel/sysrq détermine les raccourcis disponibles à tous les utilisateurs et n'est pas soumise aux permissions. Toutefois, écrire dans ce fichier exige des droits d'administrateur. Et puisque le fichier n'est pas vraiment un fichier et disparaît après extinction de la machine ou redémarrage, l'écriture doit être répétée à chaque démarrage.
L'option sysrq_always_enabled dans la ligne d'options du noyau du gestionnaire de démarrage va permettre au noyau d'ignorer /proc/sys/kernel/sysrq
Appuyez sur la combinaison de touches Alt+SysRq+Touche_Commande où SysRq est la même touche qu'Imp.Ecran et la Touche_Commande est une lettre insensible à la casse ou un chiffre compris dans la suite : b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,z,0-9
Inutile de dire qu'il est peu commode, voire infaisable d'appuyer sur les trois touches à la fois alors que deux d'entre elles sont diamétralement opposées. Faites simplement :
Maintenez appuyé sur Alt (gauche ou droite)
Appuyez puis relâchez SysRq rapidement,
Appuyez sur Touche_Commande rapidement,
Relâchez tout.
Rapidement veut dire : allez-y sans hésiter ou Ubuntu va faire apparaître une fenêtre pour confirmer la capture d'écran.
la position des touches est celle d'un clavier américain (QWERTY). Gardez cela à l'esprit lorsque vous utilisez un clavier non-américain . Par exemple q est la touche à droite de Tab, même si elle s'appelle a sur un clavier français. En réalité vous n'envoyez pas un a ou un q : vous envoyez une séquence bien défini de code-touche au kernel. Les claviers qui n'appliquent pas le code-touche des claviers traditionnels n'ont pas leur place.
Voici les informations utiles, pour ce qui nous concerne, sur seulement quelques-unes des commandes :
Tableau 2. Commandes et effets
| i | Arrête tous les processus sauf init |
| k | SAK arrête toutes les applications de la console virtuelle sur laquelle on se trouve |
| 0-9 | Définit le niveau d'enregistrement console, en gérant/et gère l'affichage des messages du kernel à l'écran : 0 pour n'avoir que les messages d'alertes, 9 pour tout afficher |
Vous vous demandez la raison pour laquelle je déclenche systématiquement un kernel panic lorsque j'appuie sur le SAK sous Ubuntu 9.10, que ce soit en mode texte ou graphique?
La différence entre les deux est que le noyau panique immédiatement en mode texte. En mode graphique tout peut sembler bien aller, mais lorsqu'on fait par exemple Alt+Ctrl+F1 pour passer en mode console c'est le drame.
Ce défaut a déjà été répertorié pour une version précédente en février 2009: https://bugs.launchpad.net/Ubuntu/+source/linux/+bug/329576/
Un commentaire ajouté au rapport de bug dit qu'il se manifeste sur les cartes mère AMD, mais pas forcément sur des Intel. Je confirme que le kernel panic a bien lieu sur du matériel AMD, mais je l'ai aussi vu sur des cartes mère Intel avec un adaptateur graphique VIA.
Un défaut similaire a été décrit pour Debian en août 2009 :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543324/
mais ici le démon ConsoleKit était le coupable. Je l'ai donc désactivé, mais le problème persiste sur mon Ubuntu.
Si on change le niveau d'enregistrement avec Alt+SysRq+9, on ouvre la vanne des informations de bas niveau à un initié. Ce qui est clair, à la lecture et l'observation, c'est qu'une tentative d' arrêt du processus 'init' a lieu, ce qui n'est certainement pas l'intention du noyau. D'où vient cette tentative d'arrêt d'init ? Il s'agit de quelque chose de propre à Ubuntu puisqu'une OpenSuse ne le fait pas.
Maintenant lorsque je fais Alt+SysRq+i pour arrêter tous les processus excepté init, j'obtiens un kernel panic exactement comme avec un SAK, avec le même message concernant la tentative de meurtre sur init.
Ce bug d'Ubuntu daté de février 2009 n'a pas reçu de suite, il n'a même pas été dévolu à un développeur, ni même vu sa priorité modifiée. Que faut-il faire pour qu'un bogue important soit corrigé dans Ubuntu?
Au final, ce que nous avons appris est inquiétant :
Tout le monde veut SysRq parce que c'est magique, sinon les distributions majeures ne l'intégreraient pas à la compilation ;
Un administrateur peut réduire les fonctionnalités de SysRq, mais pas seulement pour la plèbe. Une quelconque réduction des fonctionnalités impactera automatiquement l'administrateur. Les fonctionnalités ne peuvent être changées à la volée, car quand une situation critique apparaît on en a déjà besoin ;
Même si on ne tient pas compte des bug comme celui du SAK d'Ubuntu, SysRq possède des options pour descendre et détruire le système. Si vous commencez à les désactiver, SysRq perd un peu de sa magie lorsqu'on l'appelle dans les situations de crise ! Donc si vous désirez en tant qu'administrateur posséder SysRq, vous ouvrez au vandales et bidouilleurs une belle possibilité de mettre le bazar.
Les systèmes GNU/Linux sont-ils les systèmes les moins sécurisés dans l'histoire des ordinateurs ? Pourquoi la magie de SysRq n'est-elle pas seulement réservée à l'administrateur ?
[1]
[1] C'est une question à laquelle on peut répondre facilement, même si la réponse ne résoud en rien ce problème. Puisque la plupart des utilisateurs (espérons-le) ne sont pas la plupart du temps connectés en tant qu'administrateur, réserver la commande SysRq à l'administrateur seul rendrait cette commande totalement inaccessible au moment où l'on en aurait le plus besoin. Une approche réfléchie à ce problème serait de désactiver les options "dangereuses" par défaut, et de les réactiver sur les machines qui ont besoin d'une maintenance particulière ? --Ben
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://www.traduc.org/Gazette_Linux.
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.