Sécuriser Grub et le mode "recovery"

jeudi 20 novembre 2008
par  zarer (Christophe Gallaire)
popularité : 2%

Il est très certainement déjà arrivé à l’un de vos proches (ou "contacts") d’oublier son mot de passe (utilisateur ou administrateur). Et, comme vous l’avez lu sur un blog, un forum... il est on ne peut plus simple sur (de nombreuses distributions de) GNU/Linux de sortir de ce mauvais pas.

Le principe : modifier le mot de passe. Ou le supprimer, ce qui revient au même. Pour cela, il suffit d’avoir accès au compte root (un root shell ou terminal avec les droits d’administration) puisque seul l’administrateur peut modifier tous les fichiers. Et, paradoxalement, sous GNU/Linux, c’est un jeu d’enfant !

Paradoxalement oui... parce que cette affirmation est surprenante et se trouve en contradiction (apparente) avec l’opinion qui a cours sur la sécurité de GNU/Linux. Et l’on sait que les paradoxes pèsent au moins autant que les vérités dans la conduite des hommes... Rien n’est plus vrai que le faux !

Est-il besoin de dire ici encore que, ce qui est une commodité aux yeux de la plupart, pose d’importants problèmes de sécurité à d’autres ? Oui. Paradoxalement.

Paradoxalement parce qu’en définitive le mode "single user" est nécessaire pour un tout petit nombre de tâches administratives et qu’il est, somme toute, très rarement... nécessaire.

De fait, la plupart des (bons) guides de l’administrateur sont unanimes : par sécurité, un système correctement configuré devrait demander le mot de passe "root" avant de lancer le shell en mode "single user". Sinon, il est facile de devenir "root" en fournissant la ligne adéquate à GRUB.

De manière tout aussi paradoxale, pour beaucoup, la grande permissivité de GRUB (acronyme de GRand Unified Bootloader) serait une preuve de la maturité de GNU/Linux parce qu’il laisserait le "choix" à l’administrateur de verrouiller ou non l’accès aux fichiers vitaux du système :

Une fois de plus, Linux démontre que l’objectif d’un Système d’Exploitation reste avant tout de laisser la main à l’utilisateur... C’est ce genre de choix-là qui fait qu’un Système respecte réellement ses utilisateurs.

Afin de ne laisser aucune ambiguïté sur le sujet, je préfère le dire sans détour : cette facilité d’accès n’est nullement une vulnérabilité de GRUB (il en existe une qui permet à un attaquant local d’obtenir le mot de passe saisi au démarrage du système). Non. L’administrateur d’un système GNU/Linux (ou un autre OS libre), sans applications propriétaires, doit être responsable parce qu’il est en mesure de décider de ce que fait/autorise son propre ordinateur. Encore faut-il qu’il le sache...

Il ne peut nullement s’agir d’un "choix" si l’administrateur n’en a pas connaissance et qu’il laisse, involontairement, la possibilité à tout utilisateur qui partagerait son ordinateur (ou celui d’un espace de partage : salle informatique collective...) de modifier la configuration du système par des commandes "arbitraires" via une interface d’édition simple (bash-like).

Pour justifier cette permissivité de GRUB, les arguments ne manquent pas. Je n’ai nullement l’intention de les discuter dans la suite. Mais il en est un qui m’irrite parce qu’il opère, naïvement, par un glissement dans l’argumentation sur la nature des relations sociales : la confiance en l’autre qui est au fondement de la vie sociale.

La réalité des rapports humains est-elle si certaine, si prévisible, si simple, si monovalente ?

Comme le dit Franck Huet dans son livre Debian GNU/Linux, Sécurité du système..., « il ne faut jamais partir du postulat que tout va bien. [...] Mieux vaut anticiper les problèmes. »

Pour ma part, je reste convaincu, sans pour autant sombrer dans la paranoïa, qu’aucun système prédéfini, si rationnellement élaboré soit-il, ne pourra nous garantir jamais contre la capacité de nuisance de l’autre. Je ne peux donc que m’opposer au patch de confiance qui a été proposé pour brider GRUB.

Pour autant, par prévention, vous l’aurez compris, sur un ordinateur partagé ou un portable, je préfère limiter certains accès ouverts par GRUB pour préserver la consistance de mes données personnelles et professionnelles. Règle de base dans la stricte observance de la première loi de Raskin : Un ordinateur ne doit pas porter atteinte à votre travail ni permettre qu’il soit porté atteinte à votre travail.

Nombreux sont ceux qui prétendent que cette permissivité de GRUB est à attribuer à la distribution elle-même, à son orientation "grand public". Ce qui est vrai et faux, tout à la fois.

Faux parce que cette spécificité appartient à GRUB en propre et au mode "single user" (ou "recovery"). On a peine à croire que l’utilisateur/administrateur (je parle ici de celui qui gère sa propre machine et non de l’administrateur informé d’un parc informatique), fraîchement débarqué, en soit pleinement conscient et qu’il cherchera illico presto cette information de lui-même dès ses premiers pas sous GNU/Linux.

Pourtant, chez les migrants d’un système propriétaire bien connu qui s’orientent volontiers vers une distribution "grand public" comme Ubuntu, par exemple, la pratique du dualboot est assez fréquente. Sont-ils pour autant familiers et rompus aux subtilités de configuration de GRUB ? Je ne le crois pas. Tout bonnement parce qu’Ubuntu (comme d’autres sinon presque toutes les distributions) fait bien les choses en facilitant bien des opérations d’administration grâce à de bons outils et cela dès l’installation. Mais aucune information n’est faite sur la configuration par défaut de GRUB. Simplement, s’entend. Et, à ma connaissance, il n’existe aucun outil graphique qui permette de modifier la configuration de GRUB par défaut (l’accès au mode "single user" ou "recovery").

Dans ces conditions, peut-on réellement parler de choix ? L’administrateur est-il réellement responsable d’une configuration par défaut qu’il ne connaît pas ? Est-il vraiment en mesure de décider de ce que fait/autorise son propre ordinateur ?

La consultation de quelques nouveaux utilisateurs sur ce paramétrage par défaut en est la preuve : tous (ou presque) réclament l’intégrité de leurs données et la confidentialité des informations et des échanges. Ce ne sont là que deux principes de base de toute politique de sécurité.

Il y a donc une vraie nécessité à informer les utilisateurs/administrateurs sur ce paramétrage par défaut de GRUB voire à développer un outil simplifié d’administration qui permette son contrôle.

***

Avant d’entrer dans le détail des manipulations qui permettent de sécuriser (quelque peu) GRUB et le mode "recovery" ("single user"), vous trouverez une brève présentation dudit GRUB et quelques notions de base sur la gestion des utilisateurs.

Qu’est-ce que GRUB ?

Le chargeur (boot loader) est le premier logiciel qui s’exécute quand un ordinateur démarre. Il charge et transfère le contrôle au noyau d’un système d’exploitation (article très complet sur Wikipédia). Le noyau, à son tour, initialise le reste du système d’exploitation.

L’une des principales caractéristiques de GRUB est sa flexibilité. GRUB est un chargeur très puissant : il est capable de démarrer une très grande variété de systèmes d’exploitation (libres ou propriétaires). Il reconnaît un grand nombre de systèmes de fichiers et de noyaux.

Ainsi, pour charger un noyau, il suffit de spécifier le nom du fichier, le disque et la partition sur laquelle le noyau est enregistré. Pour que GRUB identifie le disque et le nom du fichier, il faut soit :

1. entrer les spécifications manuellement via l’interface en ligne de commande ;

2. utiliser le menu pour sélectionner l’OS qui doit être démarré. La personnalisation du menu de GRUB se fait dans le fichier de configuration. Par exemple, sous Ubuntu :

sudo gedit /boot/grub/menu.lst

Gestion des utilisateurs

Sous Linux, un utilisateur est une personne physique ou virtuelle qui possède des droits d’accès au système, un groupe d’utilisateurs et, éventuellement, un répertoire personnel.

L’utilisateur "root" est l’administrateur du système. Il a tous les droits sur le système et, de fait, sur tous les fichiers et tous les utilisateurs.

L’identification d’un utilisateur se fait par l’intermédiaire de son nom (ou login) et de son mot de passe (password).

Tous les utilisateurs sont référencés dans les fichiers /etc/passwd ou/et /etc/shadow. Le fichier /etc/group contient, lui, les références aux différents groupes. Seul "root" a le droit d’écriture sur ces fichiers.

Le répertoire personnel d’un utilisateur est en général /home/<login>. L’utilisateur peut changer son mot de passe par la commande passwd.

Pour une information plus complète, voir l’article Linux connexion.

Attribuer un mot de passe au compte "root" sous Ubuntu

Le programme init propose, entre autres, le mode de démarrage spécial "single user" (ou "recovery") qui est généralement utilisé pour des opérations de maintenance assez rares.

Au démarrage du système, en mode "single user" (sous Ubuntu "recovery"), le shell est proposé avec l’identité "root" sans aucune demande d’authentification.

Actuellement, sous Debian, pour protéger ce démarrage en mode "single user", il suffit de modifier le fichier /etc/inittab (voir la procédure). Lequel n’existe plus sous Ubuntu suite au remplacement du daemon init par Upstart.

Pour autant, il est assez simple de sécuriser le mode "recovery" sous Ubuntu :

Quand le système démarre en mode "single user" (recovery), si le compte "root" est débloqué, l’initialisation réclame le mot de passe "root" avant d’afficher le prompt.

Dans le cas contraire (configuration par défaut), le prompt "root" est affiché directement, sans mot de passe.

Pour plus de détails, voir l’excellent article Mark G. Sobell, Ubuntu’s Upstart event-based init daemon (en anglais).

J’ai lu ça et là (notamment sur le site Ubuntu-fr) que ce n’était pas beau d’activer le compte "root" sous Ubuntu :

Par défaut, sous Ubuntu, le compte root est désactivé. La logique du système est d’utiliser sudo pour effectuer toutes les tâches administratives. Il est totalement déconseillé d’activer et d’utiliser le compte root sous Ubuntu ; le présent document n’est rédigé qu’à titre informatif.

Avant que vous n’effectuez [sic] votre choix, prenez quelques secondes pour prendre connaissance des nombreux bénéfices apportés par sudo et son utilisation dans Ubuntu. Rappelons aussi que sudo n’est pas moins sécurisé que l’utilisation d’un compte root.

Sous Ubuntu, le compte "root" existe bel et bien, par défaut, mais il est bloqué. Tapez dans un terminal :

grep ’^root’ /etc/passwd

Il est bien difficile de comprendre les raisons pour lesquelles on déconseille fortement l’activation du compte "root". Aucune ne m’a réellement convaincu... sinon que la logique du système, selon Ubuntu, est d’utiliser sudo (plutôt que su) pour effectuer toutes les tâches administratives.

Ubuntu est configuré avec sudo et le compte de l’utilisateur qui est créé à l’installation du système. Autrement dit, la commande sudo permet de réaliser toutes les tâches nécessitant les privilèges de l’administrateur ("root"). Le mot de passe requis est le mot de passe du premier compte utilisateur créé.

D’aucuns affirment que cette double identité du primo utilisateur est, outre le confort de ne pas avoir à se souvenir d’un mot de passe supplémentaire (entre autres avantages "raffinés"), une sécurité supplémentaire ; le mot de passe "root" serait la cible privilégiée des attaques. Est-ce à dire pour autant que Debian et toutes les distributions qui utilisent le compte "root" plutôt que la commande sudo sont plus vulnérables aux attaques, moins sécurisées ? Oui... par induction.

Rappelons tout de même que, sous les systèmes UNIX, aucune connexion à un compte utilisateur sans mot de passe n’est possible. Y compris en tant que "root" (administrateur ou superutilisateur). Et que, normalement, seul l’utilisateur "root" a tous les droits sur tous les fichiers. Cette séparation des droits de l’administrateur et des droits de l’utilisateur est la clé de voûte de la sécurité des systèmes de type UNIX.

Sur Ubuntu, pour activer le compte "root", il suffit d’exécuter la commande suivante :

sudo passwd root

C’est d’abord le mot de passe du compte courant (du premier utilisateur créé) qui est demandé. Puis, l’invite vous demande le mot de passe souhaité pour le compte "root" qu’il sera nécessaire de saisir une seconde fois pour validation.

La même opération peut être faite depuis le mode "recovery" :

passwd root

Au (re)démarrage du système en mode "recovery", le mot passe du compte "root" sera exigé pour toute tâche de maintenance.

Pour désactiver le compte "root", il ne suffit pas d’effacer le mot de passe, il faut le bloquer :

sudo passwd --lock root

Ou depuis un shell root, tel celui du mode "recovery" :

passwd --lock root

Le simple effacement du mot de passe du compte "root" (passwd --delete root) provoque un erreur quand on tente de se connecter en tant qu’administrateur ("root").

Désactiver les options interactives de GRUB

Avant toute personnalisation du menu de GRUB, il faut agir de manière réversible ! Faites une copie du fichier de configuration. Par exemple, sous Ubuntu :

sudo cp /boot/grub/menu.lst /boot/grub/menu.lst.bak

Pour restaurer le fichier de configuration de GRUB, il suffira d’exécuter la commande suivante :

sudo cp /boot/grub/menu.lst.bak /boot/grub/menu.lst

Comme il a déjà été dit plus haut, au démarrage de la machine, il est possible de booter sur le mode "recovery". Quelle qu’en soit la raison. L’activation du compte "root" par la création d’un mot de passe rend à l’administrateur ses privilèges sur son prompt mais n’empêche nullement d’accéder à l’interface d’édition simplifiée de GRUB.

Un exemple : un utilisateur lambda peut lire /etc/passwd ou /etc/shadow depuis cette interface avec la commande cat... voire les modifier. Faites-en l’essai avec la deuxième méthode proposée par Michel Leunen ("Édition du menu grub").

Pour sécuriser le menu de GRUB, il est donc nécessaire de désactiver les options interactives du menu d’édition.

Afin que seul l’administrateur ait recours aux opérations interactives, GRUB autorise l’utilisation d’une fonction "mot de passe". Quand cette fonction est configurée, GRUB interdit tout contrôle interactif jusqu’à ce que la touche <p> soit pressée et qu’un mot de passe correct soit entré.

password [--md5] mot_de_passe [new-config-file]

Utilisée dans la première section du fichier de configuration de GRUB, cette commande désactive l’édition interactive, tout comme la commande lock.

Si le mot de passe est entré et que le chemin vers un new-config-file est renseigné (argument facultatif), la commande peut charger ce new-config-file comme nouveau fichier de configuration :

password mot_de_passe /boot/grub/menu-admin.lst

Dans le cas contraire, GRUB débloquera les instructions privilégiées.

L’option --md5 permet d’utiliser un mot de passe crypté au format md5 et d’en informer GRUB.

Si l’option --md5 est omise, GRUB suppose que le mot de passe est en clair.

Pour crypter le mot de passe au format md5, il est possible d’utiliser la commande md5crypt en invoquant le shell grub :

grub> md5crypt
Password : **********
Encrypted : $1$U$JK7xFegdxWH6VuppCUSIb

Copiez ensuite le mot de passe crypté dans le fichier de configuration.

Ajouter un mot de passe aux entrées du menu de GRUB

N’importe quel utilisateur peut choisir n’importe quelle entrée du menu de GRUB. Bien entendu, si le mot de passe "root" est requis pour démarrer le mode "recovery", les problèmes de sécurité sont circonscrits aux autres entrées du menu.

C’est là où cette option se révèle intéressante : elle permet de limiter l’exécution des autres entrées au seul administrateur. Pour démarrer un OS non fiable... DOS par exemple.

GRUB dispose d’une commande lock. Cette commande échoue toujours sauf si le mot de passe correct est entré dès le menu de GRUB (<p>). Elle doit être utilisée comme suit :

title OS non fiable
lock
rootnoverify (hd0,1)
makeactive
chainload +1

La commande lock doit être insérée juste après title.

Il est possible d’utiliser la commande password à la place de la commande lock. Dans ce cas, le processus de démarrage exigera le mot de passe et s’arrêtera s’il est incorrect.

Dans la mesure où la commande password prend en compte son propre argument, un mot de passe différent peut être utilisé pour chaque entrée du menu.


Commentaires  forum ferme

Logo de zarer (Christophe Gallaire)
samedi 22 novembre 2008 à 11h03 - par  zarer (Christophe Gallaire)

Salut Lumpy !

Oui tes remarques sont justes. Mais comme le suggère Claude (b52), le problème est assez vaste. Il s’agit juste de poser les jalons d’une réflexion sur les problèmes de sécurité courants.

Cela dit, on peut tout de même remarquer que, pour la très grande majorité des utilisateurs, une procédure en Live CD (et qui plus est le modification d’un fichier comme /etc/shadow) est tout de même pas courante et s’apparente à la pratique d’une langue étrangère ! Je sais, cette remarque ne vaut pas pour le linuxien qui parle couramment avec son terminal !

@+

Logo de Lumpy
samedi 22 novembre 2008 à 10h43 - par  Lumpy

Très bon article !

Néanmoins, j’apporterai une précision : si le BIOS n’est pas lui-même vérouillé, il est toujours possible de démarrer sur un live-CD, donc de modifier les fichiers GRUB sur le disque, et donc de redémarrer avec GRUB dévérouillé...
Donc pourquoi ne pas adopter un mot de passe BIOS en plus ?

Par contre il faut garder à l’esprit que le BIOS peut être reseté, donc au final on peut toujours ralentir mais pas vraiment empêcher l’intrusion dans une machine à laquelle quelqu’un a accès.

Logo de b52 - Claude
jeudi 20 novembre 2008 à 20h56 - par  b52 - Claude

Salut zarer,

Une fois de plus, tu nous a écrit un excellent article ;)

Le sujet de cet article pourrait être évidemment étendu à l’infini parce que la sécurité est un vaste problème mais remis dans son contexte, ce papier est une brique dont il faut tenir compte.

Merci ;)

Logo de zarer (Christophe Gallaire)
jeudi 20 novembre 2008 à 14h01 - par  zarer (Christophe Gallaire)

Bonjour SckyzO,

Comme je l’ai expliqué sur le forum, ce n’est pas "volontairement", malheureusement. Dans le cas contraire, on aurait réglé le souci...

Nous faisons de notre mieux mais le spip fait des siennes depuis quelques temps (d’où ce design de transition).

Merci de votre compréhension.

Logo de zarer (Christophe Gallaire)
jeudi 20 novembre 2008 à 13h52 - par  zarer (Christophe Gallaire)

Salut bill,

Tout dépend de la configuration de PAM.

Je parlais d’une configuration par défaut... Globalement, je pense qu’on trouve à peu la même chose d’une distribution à l’autre, non ?

Logo de SckyzO
jeudi 20 novembre 2008 à 10h30 - par  SckyzO

Bonjour,
L’article, qui est interessant, est tronqué sur le Planet Libre. Il ne respecte pas la charte disant :
- Ce flux devra en plus être complet (pas de "cliquer pour lire la suite")

En attendant il sera supprimé du Planet.

http://forum.planet-libre.org/viewt...

Cordialement,

SckyzO

Logo de bill
jeudi 20 novembre 2008 à 09h42 - par  bill

"Rappelons tout de même que, sous les systèmes UNIX, aucune connexion à un compte utilisateur sans mot de passe n’est possible."

Tout dépend de la configuration de PAM.

Logo de Thierry Andriamirado
jeudi 20 novembre 2008 à 09h37 - par  Thierry Andriamirado

"Il ne peut nullement s’agir d’un "choix" si l’administrateur n’en a pas connaissance et qu’il laisse, involontairement, la possibilité à tout utilisateur qui partagerait son ordinateur [...]" :

Tout-à-fait vrai !

Il est clair que sur ce genre de sujet, cà peut aussi être ’chacun sa chapelle’.. C’est pourquoi il est important que de telles discussions se fassent dans les listes de diffusion et sur les blogs, afin que les débutants soient sensibilisés sur ce genre de choses.

Merci pour ce très bon article !

Navigation

Articles de la rubrique

  • Sécuriser Grub et le mode "recovery"