Openssl à l'intérieur d'un chroot

Question

Je reçois l'erreur suivante lorsque j'essaie d'établir une connexion ssl à partir de l'intérieur d'une prison chroot :

twisted.internet.error.ConnectionLost: La connexion s'est perdue de manière non propre du côté opposé.

J'utilise openssl 0.9.6 avec pyopenssl pour établir la connexion ssl et j'utilise la bibliothèque twisted python pour python 2.4 sur Linux (centos 5.5).

Après quelques dépannages, j'ai découvert qu'openssl échoue car il tente de lire le fichier /dev/random et échoue car il n'y a pas de /dev/random à l'intérieur de la chroot. J'ai confirmé que si je crée un fichier /dev/random à l'intérieur de la chroot, la connexion réussit.

• J'ai pensé à monter le système de fichiers devfs qui contient le fichier /dev/random à l'intérieur de ma chroot mais mon application et ses administrateurs ont la mauvaise habitude de supprimer la racine de la chroot sans démonter tout d'abord.
• J'ai pensé à lire à partir du fichier /dev/random avant de faire la chroot mais ma configuration actuelle consiste à appeler chroot avant même que mon exécutable ne démarre, et changer l'emplacement de la chroot serait un changement trop important dans l'application que je ne sais pas quand ou comment cela pourrait être fait.
• J'ai pensé à exécuter un programme en dehors de ma prison chroot qui lit simplement à partir de /dev/random et écrit dans un tube nommé /jail/dev/random qui est accessible de l'intérieur de la prison chroot mais je n'aime pas devoir exécuter un processus séparé juste pour avoir accès à une source de données aléatoires. De plus, cela semble trop compliqué juste pour initialiser openssl.

Quelle est la bonne manière d'initialiser openssl si je n'ai pas accès à /dev/random à partir de mon programme ?

Answer 1

Vous pourriez simuler aléatoire pour openssl, par exemple en ligne de commande openssl :

[root@quilt /]# openssl s_client -h
usage: s_client args
...
 -rand file:file:...
...

Quoi qu'il en soit, openssl a besoin d'une source d'aléatoire, il ne peut pas être sécurisé sans nonce aléatoire, par exemple sur wikipedia :

Pour générer les clés de session utilisées pour la connexion sécurisée, le client chiffre un nombre aléatoire avec la clé publique du serveur et envoie le résultat au serveur. Seul le serveur devrait être en mesure de le déchiffrer, avec sa clé privée.

Sans source d'aléatoire, SSL/TLS peut être facilement piraté.

Si vous craignez que chroot/dev/ puisse être supprimé, pourquoi ne créer que chroot/dev/random ou chroot/dev/urandom au lieu de monter tout le dev ?

[root@quilt /]# mknod /dev/random c 1 8
[root@quilt /]# mknod /dev/urandom c 1 9

Au fait, vous voudrez aussi copier le fichier system /etc/resolv.conf et éventuellement d'autres fichiers hosts, services, ethers, etc...

Answer 2

Peut-être qu'une meilleure façon est de monter les fichiers de périphérique de la manière suivante :

# touch chroot/dev/random
# mount --bind /dev/random chroot/dev/random

et de faire de même pour urandom.

Answer 3

N'oubliez pas SELinux après avoir créé urandom et random

cat /var/log/messages | grep "SELinux is preventing"

SELinux empêche /usr/sbin/php-fpm d'accéder en lecture au fichier de périphérique urandom.

Si vous pensez que php-fpm devrait avoir un accès en lecture par défaut au fichier de périphérique urandom.
Alors vous devriez signaler ceci comme un bug.
Vous pouvez générer un module de politique local pour autoriser cet accès.
Autorisez cet accès pour le moment en exécutant:

ausearch -c 'php-fpm' --raw

audit2allow -M my-phpfpm

semodule -i my-phpfpm.pp