Dans mon article précédent C’est décidé, je retourne sous Linux, je me moquais gentiment sur le Windows livré sur mon nouveau pc (un Dell Vostro 3360, comme ça vous saurez tout). Après tant d’amusement trollesque, j’ai voulu installer un système Archlinux aux petits oignons qui me convenait. Comme je trouve que la ligne de commande reste le moyen le plus efficace et rapide de faire du peaufinage de système, on va en bouffer ! La procédure ci-dessous explique comment obtenir une installation d’Archlinux dans un conteneur LVM chiffré avec dm-crypt et LUKS (système et SWAP) avec l’activation de TRIM pour SSD et une utilisation de Enlightenment E17 comme windows manager.

Kwa ? G rien compri !

Voici ce dont on parle :

  • Archlinux : mon coup de coeur dans les distributions de linux, les explications devraient pouvoir être adaptable à d’autres systèmes tant que vous avez un terminal à disposition.
  • LVM : méthode de gestion de partitions non continues. On peut ajouter, supprimer, modifier les partitions un peu comme on veut, plus besoin de rester 3h devant GParted en priant le dieu Bécup.
  • LUKS : norme de chiffrement par blocs, idéal sous linux pour chiffrer une partition (en opposition à par exemple à eCryptfs qui sert à chiffrer un dossier comme le propose Ubuntu avec le dossier home)
  • dm-crypt : sous-système permettant de gérer le chiffrement LUKS (où se trouvent les clefs…) utilisé par le noyau Linux. Propose notamment cryptsetup que l’on utilise ici.
  • SSD : nouvelle génération de disques remplaçant les vieux HDD. Plus rapides, silencieux, économes en énergie et surtout plus chers. Mon Vostro est équipé d’un SSD de 128GB (pas de HDD en hybride)
  • TRIM : sur un HDD, lorsque l’on écrit là où se trouvaient des données “supprimées”, on écrase l’ancienne valeur par la nouvelle. Avec un SSD, on doit d’abord supprimer le contenu du secteur puis écrire la nouvelle (perte de performances). TRIM permet d’indiquer au système lorsque l’on n’a plus besoin de certaines données, l’autorise à les supprimer et l’on gagner du temps pour la future réécriture. Une sorte de garbage collector. De par son mode de fonctionnement, TRIM rend aussi inefficace toute tentative de récupération de données en cas de rm mal placé.
  • SWAP : espace du disque dédié à soulager la RAM lorsque celle-ci se retrouve surchargée. Il est nécessaire de la chiffrer pour éviter les fuites d’information (des mots de passe pouvant être chargé dans la RAM).
  • E17 : window manager léger et hyper personnalisable (*tousse*opposé de GNOME*tousse*). Une version stable vient de sortir après 12 ans de développement. Au passage ne venez pas m’ennuyez sur le window manager vs desktop environment, on met un peu n’importe quoi dans les deux catégories et puis c’est moi qui décide ici, na !

Voici une image permettant de mieux comprendre ce que l’on va réaliser :

luks-graph

Le /boot est sur une petite partition séparée (on a besoin d’un certain nombre de modules pour déchiffrer la partition), le reste du système se trouvant dans une partition chiffrée. En déchiffrant cette partition, on ouvre un conteneur LVM. Cela permet d’avoir toutes les partitions chiffrées avec la même clef. Si l’on voulait chiffrer une seule partition (ou plusieurs avec des clefs différentes), l’on aurait fait le contraire (LUKS dans LVM). Dans mon cas, n’ayant qu’Archlinux sur un petit disque, j’ai préféré utiliser uniquement une SWAP et une partition pour le système. Libre à vous de diviser le conteur LVM en plus de parties pour un home séparé ou pour du multiboot.

La manipulation va donc permettre de chiffrer sa machine, cela ne rendra pas la machine invisible contre tout types d’attaque. Les implications exactes en termes de sécurité sont mentionnées dans la conclusion, lisez là bien avant de commencer toute manipulation si vous n’êtes pas certains de bien comprendre.

Préparation

Attention, cette procédure va écraser lamentablement vos précédentes données tel le scarabée rhumatisant sous la patte du vaillant hippopotame. Si vous voulez conserver une copie de votre disque, je vous conseille de suivre cette procédure. Suumitsu a donné une procédure permettant de convertir un disque en machine virtuelle. J’ai testé mais perso la machine virtuelle ne fonctionne pas chez moi (récup système qui échoue).

Créez un live CD ou USB, démarrez dessus jusqu’à obtenir un terminal utilisable (je passe cette étape, pour arch c’est ici que ça se passe, jusqu’au 2.2). Fait ? Maintenant on efface le tout. D’abord on met de l’aléatoire pour maximiser la sécurité (on ne peut pas différencier les données aléatoires des données chiffrées). Note : l’activation de TRIM réduit l’intérêt de cette manipulation, lisez la dernière section sur les limites pour vous faire une opinion. Si vous jugez cela inutile, passez cette étape (je la laisse sans être certain à 100% de ce que j’avance). Si vous avez un HDD, faites le.

$ dd if=/dev/urandom of=/dev/sda

Ouille pauvre disque, ça prend du temps (6 MB/s sur mon disque de 128GB, soit 6 heures, glups). C’est pas le mode le plus parano du monde mais ça suffit. Faire plusieurs réécritures a été montré comme superflu. En parlant de suppression efficace, n’utilisez pas non plus des outils comme shred en pensant bien effacer vos fichiers, c’est inefficace sur un SSD.

Partitions

On crée ensuite une nouvelle table de partition. J’ai utilisé cfdisk, c’est très facile et interactif, même pas besoin de lire la man page pour comprendre. Les partitions sont à définir selon vos gouts mais comme je vous le disais plus haut, je vais uniquement séparer /boot du reste. 200MB pour /boot sur sda1, le reste sur sda2.

# cfisk /dev/sda
# mkfs.ext4 /dev/sda1 -L boot # EXT4 est bien mais c’est un choix personnel après

Pour chiffrer sda2, on a plusieurs choix d’algorithmes, de modes de stockage de clef, etc. On peut par exemple utiliser une suite de bytes aléatoires qui sont stockés sur une clefs USB chiffrée avec GPG (not bad). Mais nous, on ne vise pas la top sécurité (trop contraignant je trouve), on va faire au plus simple : un mot de passe à entrer au boot. Lisez la man page ou ce wiki pour des variations. (désolé pour cet idiot de wordpress qui me remplace les doubles tiret par un caractère spécial)

# cryptsetup –cipher aes-cbc-essiv:256 –key-size 256 –hash sha256 –iter-time 1000 –use-random –verify-passphrase luksFormat /dev/sda2

On choisi un super mot de passe (que vous irez écrire sur un post-it collé à l’écran) et on confirme (n’oubliez pas les majuscules pour le “yes”).

Pour ouvrir le conteneur, on utilise la commande suivante (très important, c’est cette commande que vous allez utiliser si jamais vous crachez votre système et devez faire la réparation avec un live cd, notez la aussi sur le post-it) :

# cryptsetup luksOpen /dev/sda2 sda2_crypt

La partition est maintenant accessible à /dev/mapper/sda2_crypt (vous pouvez évidement choisir un autre nom).

La partition sda2_crypt va être convertie en Primary Volume LVM contenant la swap et /. Je conseille encore une fois la doc archlinux pour les variations mais dans mon cas :

# modprobe dm-mod
# pvcreate /dev/mapper/sda2_crypt
# vgcreate MyGroup /dev/mapper/sda2_crypt
# lvcreate -C y -L 1G MyGroup -n lvswap
# lvcreate -l +100%FREE MyGroup -n lvarch
# mkswap /dev/mapper/MyGroup-lvswap
# mkfs.ext4 /dev/mapper/MyGroup-lvarch -L arch
squelette à un bar

Kevin attend patiemment que son algorithme de brute force trouve votre clef LUKS

Installation

Maintenant on peut continuer normalement l’installation comme n’importe quel système. Dans le cas d’Archlinux avec arch-chroot, il faut d’abord monter les partitions dans /mnt.

# mount /dev/mapper/MyGroup-lvarch /mnt
# swapon /dev/mapper/MyGroup-lvswap
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Dans le beginner’s guide d’archlinux, on peut reprendre au point 2.6. select a mirror. Les partitions montées étant déchiffrées, la génération du fichier fstab devrait donner les bons UUID.

Dans le cas de mon Dell Vostro 3360, le wifi était reconnu nativement mais pas ethernet, la faute à l’Atheros AR8161. J’ai expliqué la marche à suivre mais à ce jour (à adapter à sa version du noyau, deviendra compat-driver dès linux 3.7), les commandes sont :

# wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.6/compat-wireless-3.6.8-1-snpc.tar.bz2
# tar xjf compat-wireless-3.6.8-1-snpc.tar.bz2
# cd compat-wireless-3.6.8-1-snpc
# ./scripts/driver-select alx
# make
# make install
# modprobe alx

Avant que vous ne redémarriez, il faut faire quelques modifications pour activer le déchiffrement et TRIM. Dans le fichier /etc/mkinitcpio.conf, on défini les modules à charger dans le noyau au démarrage. Voici ce qu’il faut dans notre cas :

MODULES="... sd_mod .."
...
HOOKS="... keymap encrypt lvm2 resume filesystems ..."

sd_mod étant pour LVM, keymap pour charger la disposition du clavier que vous aurez spécifié dans /etc/vconsole.conf (attention, si pas présente, vous devrez déchiffrer votre partition en qwerty), encrypt pour LUKS, LVM2 pour LVM (inattendu je sais), resume pour sortir de l’hibernation et tout cela devant se trouver avant filesystems. Vous pouvez également faire un nettoyage ici en supprimant et déplaçant quelques modules. Je ne suis pas spécialiste de cette partie donc ne vais pas trop m’aventurer là dedans de peur de dire des conneries. Si ça vous intéresse Postblue en donne quelques unes (des optimisations, pas des conneries).

On régénère l’image à charger avec :

# mkinitcpio -p linux

(ou autres paramètres en cas de noyau différent ou optimisation)

Pour indiquer à GRUB la marche à suivre, on va modifier le fichier /etc/default/grub à la ligne GRUB_CMDLINE_LINUX pour mettre :

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:sda2_crypt:allow-discards resume=/dev/mapper/MyGroup-lvswap pcie_aspm=force elevator=noop"

N’oubliez pas de regénérer un nouveau fichier grub.cfg avec grub-mkconfig. Le allow-discards permettant d’activer TRIM. On va d’ailleurs également modifier le fichier /etc/fstab qui chez moi ressemble à ça :

# /dev/mapper/MyGroup-lvarch LABEL=arch
UUID=8f42... / ext4 defaults,noatime,nodiratime,discard 0 1

# /dev/sda1 LABEL=boot
UUID=dd30... /boot ext4 rw,relatime,data=ordered 0 2

# /dev/mapper/MyGroup-lvswap
UUID=2142... none swap defaults,noatime,nodiratime,discard 0 0

J’avoue ne pas être certain à 100% des paramètres en dehors du discard, les nomachin permettant de réduire le nombre d’écriture nécessaire (mais peut poser des problèmes dans certains cas de figure). Lisez SSD Tuning For Linux ou Archlinux SSD pour plus d’info.

Démarrage et E17

J’ai choisi d’installer E17 comme environnement de bureau. C’est très léger et très personnalisable. Tellement personnalisable que je n’ai pas encore réussi à l’adapter complètement à mes envies mais je suis sur que ça arrivera (j’ai commencé à mettre une série d’astuces ici). Voila à quoi ça ressemble chez moi après installation.

bureau-e17

Sobre et léger, moi j’aime ( fond d’écran)

Il suffit d’installer le paquet enlightenment17 pour obtenir le bureau ainsi que tous vos programmes favoris et légers pour les tâches voulues (connman pour la gestion du wifi, mirage pour les images, 7-zip pour les archives… à vous de voir). Comme pour n’importe quel environnement de bureau en somme.

Là par contre où une modification devient intéressante est la connexion automatique. Si l’on chiffre le disque, l’intérêt de demander le mot de passe de l’utilisateur directement après est diminué. L’optimisation vient de chez postblue qui la tient du wiki Archlinux. Connexion automatique sur votre utilisateur qui va lancer Enlightenment avec un exec enlightenment_start dans le fichier ~/.xinitrc.

Grâce à ces optimisations, sur mon Vostro, une fois le mot de passe LUKS entré, j’ai besoin de 3 secondes pour être sur un bureau prêt à l’utilisation, c’est moins que ce qu’il me fallait pour sortir d’hibernation sur mon ancienne machine !

Vérification TRIM

Alors là, pour être honnête, j’ai une incertitude. Cela a été le sujet d’une discussion sur les forums Archlinux (ici) sans arriver à de solution convenant tout le monde. De nombreux sites affirment que le flag “allow-discards” suffit à activer TRIM. On peut le vérifier ainsi :

# dmsetup table /dev/mapper/sda2_crypt –showkeys
0 249583634 crypt aes-cbc-essiv:sha256 f7[… ]95 0 8:2 4096 1 allow_discards

Si on leur fait confiance (ce que j’ai envie de faire), cela devrait suffire.

Seulement “discard” indique que l’on active TRIM, pas que TRIM fonctionne (vous voyez la subtilité ?). Un test un peu plus sophistiqué est donné ici. Cela consiste en la création d’un fichier, regarder où il se trouve en mémoire, le supprimer et vérifier que le registre a bien été vidé (les commandes sont dans le lien). Cependant lors du test, je découvre que les secteurs en questions sont vides avant d’avoir supprimé le fichier.

Avec un peu de recherche, j’ai trouvé ce blog donnant une piste de réponse. Il faudrait en réalité faire une addition sur l’alignement des partitions pour obtenir la bonne valeur. J’ai réalisé l’exercice ici avec un résultat différent mais tout autant décevant : une série de bytes aléatoires dans le secteur calculé mais pas supprimés à la suppression du fichier. Erreur de calcul ? Non activation de TRIM ? Problème avec la couche d’abstraction LUKS+LVM ? Mystère. Si quelqu’un a plus d’idées, je suis sur que ça en intéressera certains.

Conclusion et limites du chiffrement

La sécurité obtenue n’est pas absolue mais est déjà très raisonnable. Chiffrer votre disque ne vous protègera pas complètement. Il n’y a pas de problèmes si vous perdez votre machine hors ligne (pas de logiciels types Prey donc, pas grave, je préfère) mais il existe des cas plus problématiques. Le fait d’entrer votre mot de passe signifie qu’un attaquant ayant accès à votre PC est potentiellement capable de modifier vos fichiers de boot pour y ajouter un keylogger par exemple. Le cas de la clef sur une clef USB diminue un peu ce risque mais est assez contraignant (à vous de voir votre besoin de sécurité).

L’activation de TRIM réduit également la sécurité. Lisez cet article par un développeur de cryptsetup pour comprendre le problème. En autorisant le système à vider tous les secteurs inutilisés, l’on va permettre la détection des secteurs utilisés et ceux qui ne le sont pas. C’est pour cela que j’affirmais plus haut que le remplissage du disque de random était sans doute inutile. Cela ne me pose pas de problème pour mon utilisation de la machine mais il faut le savoir.

Une fois la partition déchiffrée, LUKS ne sert plus à rien évidement. Le chiffrement ne vous protègera pas contre les failles de sécurité dans vos logiciels. Il est par exemple important de verrouiller votre machine en veille. Il n’est pas à ma connaissance possible d’accéder au contenu d’une machine verrouillée sans faire d’attaque physique (contenu de la RAM par ex), vous devriez donc être à l’abri des script-kiddies si vous n’avez pas laissé de failles grosse comme une maison (si vous voulez vous protégez contre des gouvernements, pensez qu’ils possèdent d’autres moyens d’obtenir les clefs que de pirater votre machine).

Au passage, je conseille vivement de ne pas choisir le même mot de passe pour LUKS et votre utilisateur. Il est beaucoup plus facile d’avoir un keylogger ou d’accéder aux hash de votre mot de passe lorsque votre machine fonctionne.

Bonus : détectez les modifications de /boot

Je disais plus haut que le problème sécurité le plus préoccupant avec cette configuration était qu’une manipulation offline pouvait tout foutre en l’air. Si l’attaquant arrive à bidouiller les fichiers dans /boot, il peut faire beaucoup ; même une clef présente sur une clef USB peut se faire enregistrer avec un script malveillant. Heureusement, une publication dans ct-magazine donne une solution : vérifier le hash du MBR et des fichiers une fois la partition déchiffrée (les hash sont chiffrés évidement). Si une modification est détectée, grosse alerte !

Téléchargez l’archive suivante 1203-146.zip par l’auteur de l’article ou ma version qui utilise sha256 plutôt que sha1 (qui, si toujours sécurisé aujourd’hui, risque de ne plus l’être très longtemps, surtout depuis cette nouvelle attaque), ajoute le fichier de config systemd, enlève un espace au début de chkboot.sh (plantait le lancement de systemd) et ajoute un fichier .desktop pour chkbook_user.sh. Si je suis pas trop sympa quand même !

# cp chkboot.sh /usr/local/bin/chkboot.sh
# chmod +x /usr/local/bin/chkboot.sh
# cp chkboot_user.sh /usr/local/bin/chkboot_user.sh
# chmod +x /usr/local/bin/chkboot_user.sh
# cp chkboot@.service /etc/systemd/system/chkboot@.service
# systemctl enable chkboot@.service
# mkdir /var/chkboot
# /usr/local/bin/chkboot.sh

Le script chkboot_user.sh utilise zenity pour les alertes. Veillez à ce qu’il soit installé. Démarrez ce script au démarrage de votre session. Cela peut se faire via l’interface graphique de window manager préféré ou en ajoutant un fichier .desktop (comme celui dans l’archive que je vous donne par exemple) dans le dossier ~/.config/autostart/. Dans le cas de E17, le dossier autostart n’est pas utilisé (juste pour GNOME, KDE et XFCE). À la place, placez le fichier .desktop dans ~/.local/share/applications/ et allez ensuite dans settings > apps > startup applications >
applications
et activez l’application Chkboot.

alert-changes-detected-boot

Avec la liste des fichiers ayant changé de hash

Attention, le script chkboot.sh est à faire tourner à chaque modification du dossier /boot. Cela peut arriver souvent sous Archlinux (à chaque mise à jour du noyau ou de grub par exemple). Si vous trouvez cela trop contraignant, n’hésitez pas créer un alias type alias sysupdate="/usr/local/bin/chkboot_user.sh && yaourt -Syua && /usr/local/bin/chkboot.sh".

PS : j’ai commencé la rédaction de la page en français au sujet de LUKS sur le wiki archlinux.fr. N’hésitez pas à venir contribuer, c’est encore bien vide.

Pacman 4.0 vient de passer de [testing] à [core] sur archlinux. Cette version apporte beaucoup de nouveautés mais surtout la signature des paquets.

Avertissement: si vous ne savez pas ce qu’est gpg ou le principe de signature, allez lire ceci, un peu vieux mais toujours aussi accessible et valable.

L’idée est de garantir, via la signature, que le paquet que l’on télécharge a réellement été créé par le développeur et qu’il n’y a pas eu modification (pour insérer une backdoor au milieu par exemple). Seulement on ne veut pas importer la clef publique de chaque développeur et la signer, ça serait inefficace et il faudrait les vérifier une à une si l’on voulait être sûr de sa validité (ce que franchement, personne ne fera). GPG utilise un système de web of trust pour la gestion des clefs qui revient plus ou moins à les amis de mes amis sont mes amis, vous ferrez confiance à une clef si elle a été signée par quelqu’un à qui vous faites confiance.

Archlinux possède plusieurs catégories de personnes dans la communauté : les développeurs (responsables pour [core] et [extra]), les utilisateurs de confiance (responsables pour [community]) et les master-keys. Pour qu’une clef soit acceptée, elle doit avoir été signée par au moins 3 des 5 master-keys. Chaque master possède un certificat de révocation pour la clef d’un autre master. Ainsi aucune de ces 5 autorités de confiance n’a un pouvoir absolu.

Pacman implémente donc désormais cette fonction de signature des paquets pour une sécurité accrue (et ça c’est bien). Si votre pacman est bien configuré au départ, ça ne changera quasi rien pour vous. Les seules différences seront lorsqu’il y aura un problème de sécurité (et vous serez alors content d’avoir configuré pacman somme toute). Pour faire une comparaison avec les autres packages manager, les autres implémentent d’habitude la vérification avec gpgv, qui suppose que toutes les clefs publiques importées dans votre keyring sont de confiance (bof) tandis que gpgme, utilisé dans pacman, supporte complètement le web of trust, si important pour ce genre de système. Les attaques les plus populaires sur les packages manager ont été empêchées avec, en plus, la signature des bases de données, la rétention de mise à jour sur des dépôts malicieux ou les flux de données sans fin (qui visiblement étaient possibles avant).

Par défaut la vérification des signatures est désactivé sur arch pour ne pas forcer à configurer le tout mais nous allons régler ça !

D’abord assurez vous que vous possédez bien la version 4 de pacman avec un simple pacman -Qs ^pacman$. Une fois fait (mettez à jour sinon, pacman -Rtt pour les paquets en conflits style package-query), commencez par générer les trousseaux de clefs nécessaires avec pacman-key --init, vous possédez maintenant une jolie clef de 2048bits.

$ pacman-key --list-keys
gpg: NOTE: trustdb not writable
/etc/pacman.d/gnupg/pubring.gpg
-------------------------------
pub 2048R/3D538099 2012-01-17
uid Pacman Keychain Master Key

Ouvrez maintenant le fichier /etc/pacman.conf (après merge avec pacman.conf.new généré à la mise à jour) et réglez les paramètres SigLevel pour chaque dépot. Ce dernier vaut par défaut Never, on a le choix entre deux valeurs acceptables Optional et Requiered. La première veut dire vérifiez la signature si présente, acceptez sans signature s’il n’y en a pas. Si ce paramètre est acceptable pour la transition, on ne veut pas le garder et le changer dès que possible pour Required (obliger la vérification). Par défaut, une clef ne sera acceptée que si on la juge de confiance (autorité de confiance a signé le certificat par exemple), on ne va pas changer ça mais si jamais vous vouliez le faire (pour une raison x ou y), rajoutez TrustAll sur la même ligne (à la place du TrustedOnly sous-entendu).

Attention, tous les dépôts ne sont pas encore entièrement signés ! Pacman 4 est stable mais il reste quelques détails pratiques sous arch pour assurer que tout est bien fait. Tous les paquets de [core] sont signés mais pas tous dans [extra] ou [community] et, de plus, les bases de données de ces trois dépôts ne sont pas non plus signées. En attendant que ce soit fait, on va donc être un peu moins difficile. Toujours dans pacman.conf, mettez Optional en global et pour les dépôts PackageRequired, Optional et Optional respectivement pour [core], [extra] et [community].

Si vous essayez de télécharger un paquet maintenant, cela vous sera refusé car vous ne faites pas confiance aux clefs gpg utilisées.

$ pacman -S ruby
resolving dependencies...
looking for inter-conflicts...

Targets (2): libyaml-0.1.4-1 ruby-1.9.3_p0-3

Total Download Size: 0.07 MiB
Total Installed Size: 20.16 MiB

Proceed with installation? [Y/n] y
:: Retrieving packages from community...
libyaml-0.1.4-1-x86_64 [#####################] 100%
(2/2) checking package integrity [#####################] 100%
error: ruby: key "FCF2CB179205AC90" is unknown
:: Import PGP key 9205AC90, "Eric Belanger ", created 2011-04-20? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

(Je la refuse car je n’ai pas envie de devoir faire ça un par un pour chaque développeur…)

Pour régler ceci, on va importer les clefs nécessaires. Si vous me faites confiance (attention il y a un piège), vous pouvez exécuter le script suivant (en tant que root).

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done

Ceci va importer les 5 master-keys nécessaires dans votre keyring et leur donner la confiance marginal (3 signatures marginales sont requises pour faire confiance à une clef). Cependant, il est conseillé d’aller vérifier chaque signature sur la page des mester-keys et de vérifier les fingerprints (pacman-key --finger des clefs. Bien sûr ça ne garantit pas que la page d’archlinux ai été hackée mais ça réduit déjà le risque.

Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Malheureusement on y est pas encore. Vous avez ainsi les master-keys qui sont bien importantes mais il vous faut encore importer les clefs des développeurs et des trusted users. Cela se fait rapidement via

curl https://www.archlinux.org/{developers,trustedusers}/ |
awk -F" '(/pgp.mit.edu/) {sub(/.*search=0x/,"");print $1}' |
xargs pacman-key --recv-keys

Notez que ce code ne fait qu’importer les clefs, on ne les signe pas. Tout l’intérêt du wot est justement de ne pas devoir signer les clefs des développeurs, si une clef d’un attaquant s’est glissé dans cette liste, ce n’est pas grave car elle n’aura pas été signée par les master-keys. Lorsque l’on télécharge un paquet, pacman vérifiera qui a signé le paquet, s’il se trouve dans notre keyring et est valable (3 marginal). Si ces conditions ne sont pas remplies, vous recevrez une erreur et il faudra y regarder. Cas 1: un nouveau développeur ou un possédant une nouvelle clef, vous pouvez l’importer, si elle est signée par 3 master-keys, ça passera. Cas 2: un attaquant a modifié une signature, importer la clef, elle sera refusée car invalide. De temps en temps (particulièrement si une mise à jour à échouée), vous pouvez rafraichir la base de donnée des clef via pacman-key —refresh-key.

Et vous voila avec un pacman bien sécurisé à l’abri des attaques principales sur la distribution de paquets ! Suivez bien l’actualité archlinux pour savoir quand demander la signature de base de donnée et passer de Optional à Requiered partout (bon par contre pour aur, on est pas prêt d’y arriver). J’espère que ça vous a été utile !

[Source]

CC XKCD

Si vous essayez de mettre à jour votre machine archlinux, vous rencontrerez sans doute l’erreur suivante :

error: failed to commit transaction (conflicting files)
filesystem: /etc/mtab exists in filesystem
Errors occurred, no packages were upgraded.

Cette erreur est due au fait le fichier était anciennement généré au boot et n’appartenait à personne. Désormais, il s’agit d’un lien symbolique vers /proc/self/mounts appartenant à filesystem.

Pour régler le problème, il suffit de forcer la mise à jour :

$ pacman -S filesystem ––force

[Source]

Linux 3.0 sur Archlinux

8 August 2011

Comme à son habitude de ne pas avoir peur des changements (ça doit faire un an que python=python3, ce qui me casse encore 2, 3 scripts mal foutus), Archlinux a fait la mise à jour de son kernel pour passer à la version 3.
Changements non pas parce que ce kernel apporte plein de nouveautés (il n’en apporte pas plus qu’une mise à jour habituelle) mais parce que quelques fichiers importants changent de nom.

  • vmlinuz26 devient vmlinuz-linux
  • kernel26.img devient initramfs-linux.img
  • kernel26-fallback.img devient initramfs-linux-fallback.img

Pour ne pas tout casser, des liens ont été créés entre les anciens et les nouveaux fichiers. Il est donc conseillé de mettre à jour ses config grub et autres pour pouvoir supprimer ces liens manuellement.

Si vous êtes sur Fedora, le kernel 3.0 porte d’ailleurs le nom 2.6.40 pour laisser aux gens le temps d’adapter leurs scripts (cf Dave Jones, là où Linus Torvalds dit que Gnome 3 c’est de la me***).

[Source]

Cela faisait un petit temps que je n’avais rien posté (parce que je n’avais rien à dire surtout) donc je vais remédier à ça.

Depuis quelques temps mon debian devenait un peu trop capricieux et avait des problèmes de partout, ça doit faire à peut prêt 8 mois que je l’ai, beaucoup de trop. Je ne dis pas qu’il faut réinstaller son système tout les 6 mois, (ça c’est bon pour windows :-D ). Juste que quand on trifouille son système dans tout les sens, installe un nouveau pilote machin, le remplace par un autre sans désinstaller complètement le premier,… ça amène des problèmes !

Plutôt que de prendre des bonnes résolutions à chaque réinstallation, je… réinstalle.
Comme ça faisait un bout de temps que j’avais un ami qui me rabâchait les oreilles avec ça, j’ai décidé de tester ArchLinux.

Lire la suite… »