Pourquoi / dev / urandom est-il uniquement lisible par root depuis Ubuntu 12.04 et comment puis-je le «réparer»?

10

J'avais l'habitude de travailler avec des modèles Ubuntu 10.04 sur de nombreux serveurs. Depuis le passage à 12.04, j'ai des problèmes que j'ai maintenant isolés.

Le périphérique / dev / urandom n'est accessible qu'à root.

Cela a provoqué l'échec des moteurs SSL, au moins en PHP, par exemple file_get_contents (https: // ...

Il a également brisé la mine rouge.

Après un chmod 644, cela fonctionne bien, mais cela ne reste pas au redémarrage.

Donc ma question.

Pourquoi est-ce? Je ne vois aucun risque pour la sécurité parce que ... je veux dire ... tu veux voler des données aléatoires?
Comment puis-je le "réparer"? Les serveurs sont isolés et utilisés par une seule application, c'est pourquoi j'utilise openvz. Je pense à quelque chose comme un script de niveau d'exécution ou plus ... mais comment le faire efficacement? Maby avec dpkg ou apt?
Il en va de même pour vor / dev / shm. dans ce cas, je comprends parfaitement pourquoi ce n'est pas accessible, mais je suppose que je peux le "réparer" de la même manière pour corriger / dev / urandom

— Le Shurrican
source

Que ls -l /dev/urandommontre- t -on avant de modifier les autorisations? Avez-vous personnalisé des fichiers /etc/udev/rules.dou /lib/udev/rules.d?

— David Schwartz

root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom- Je n'ai rien défini, c'est un serveur vierge, même la mise à jour apt-get n'a pas encore eu lieu.

— Le Shurrican

3

La documentation indique spécifiquement que les autorisations devraient être 0644. La question est - pourquoi pas?!

— David Schwartz

1

FWIW, sur mon Precise fraîchement installé, / dev / urandom est 0666. Lors de l'installation, j'ai choisi "serveur openssh" comme seule option de rôle. Peut-être qu'un paquet dans votre configuration fait quelque chose de stupide.

— cjc

je suis d'accord. mes règles udev disent aussi que ça devrait l'être. je pense que cela a quelque chose à voir avec la virtualisation.

— Le Shurrican

3

Avec une lecture excessive d'udev, vous pouvez vider le pool aléatoire, résultant en des nombres aléatoires prévisibles. C'est probablement la raison pour laquelle / dev / urandom n'est pas disponible pour tout le monde. (supprimé car Graeme Donaldson a raison)

Dans le cas où vous souhaitez toujours modifier l'autorisation, examinez les règles udev responsables de la définition des modes sur / dev / urandom, au lieu de gâcher vos scripts d'initialisation.

Sous Debian, il est facile de trouver la règle coupable:

$ dpkg -L udev | xargs grep urandom
/lib/udev/rules.d/91-permissions.rules:KERNEL=="urandom", MODE="0666"

Dans votre cas, MODE n'est certainement pas 0666.

Modifiez-le selon les règles de configuration udev, si vous le souhaitez.

Remarque: http://lists.centos.org/pipermail/centos/2009-July/079134.html peut aider à changer udev.

Vous aurez essentiellement besoin de créer une règle qui ressemble au résultat grep, sauf qu'il a un mode correct défini, et l'ajouter en tant que fichier de règles dans /etc/udev/rules.d/ (attention aux différences possibles dans Ubuntu et Debian !)

— asdmin
source

Si / dev / urandom n'est lisible que par root, alors OpenSSH et les logiciels qui se lient à OpenSSL, GnuTLS et à d'autres bibliothèques de cryptographie devraient soit s'exécuter en tant que root, soit démarrer en tant que root, puis supprimer les privilèges. D'une certaine manière, cela semble bien pire.

— Gerald Combs

3

/ dev / urandom ne dépend pas du pool d'entropie. Seule la lecture de / dev / random provoque l'épuisement du pool d'entropie.

— ThatGraemeGuy

Gerald: sshd démarre en tant que root. Par exemple, pour lier le port 22 et pour répondre à l'utilisateur connecté, etc.

— asdmin

root @ redmine: ~ # dpkg -L udev | xargs grep urandom /lib/udev/rules.d/50-udev-default.rules:KERNEL=="null|zero|full|random|urandom ", MODE =" 0666 "root @ redmine: ~ # ls -lha / dev / urandom crw ------- 1 root root 1, 9 Jul 2 12:39 / dev / urandom cela ne ressemble vraiment pas à une mauvaise configuration mais à un bug, mais il est corrigé dans le nouveau modèle d'installation openvz!

— The Shurrican

@ThatGraemeGuy Je me rends compte que je suis en retard à la fête, mais ce n'est pas tout à fait correct. /dev/random se bloque lorsque l'estimation d'entropie est faible, tout en /dev/urandomcontinuant à produire des nombres pseudo-aléatoires même lorsque l'estimation d'entropie est faible. Cela dit, le concept entier du pool d'entropie "d'une manière ou d'une autre aléatoire" est trompeur et dénué de sens .

— Stephen Touset

1

Quant à la façon dont vous pouvez le réparer, un pansement temporaire serait de simplement

cat "chmod 666 /dev/urandom" >> /etc/rc.local

— michel-slm
source

que j'ai essayé mais qui n'a pas fonctionné. maintenant j'ai ajouté la commande chmod juste en bas de /etc/rc0.d/S30urandom ... qui a fonctionné

— The Shurrican

Il y a des problèmes qui pourraient empêcher /etc/rc.local de provenir correctement d'Ubuntu - y compris son autorisation (il doit être marqué comme exécutable). voir ici: bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/882254

— michel-slm

avait l'air prometteur mais n'aide pas. aussi le rc.local ne semble pas être exécuté, j'ai essayé d'écrire un fichier simple sur tmp mais cela n'a pas fonctionné aussi. les autorisations sont correctes. j'ai essayé avec execute pour root seulement, reste lu et aussi 777 ...

— Le Shurrican

2

étant donné que la solution est probablement spécifique à Ubuntu, AskUbuntu est probablement un meilleur pari à ce stade. J'utilise béatement systemd, et /etc/rc.d/rc.local fonctionne juste sans problème comme il l'a fait avec les scripts systèmeV: /

— michel-slm

Notez que vous devez modifier le /etc/rc.localfichier. Dans mon cas (Ubuntu 16.04), le fichier s'est terminé avec la sortie 0, donc si vous ajoutez simplement une ligne, cela ne fonctionnerait en effet pas.

— Alexis Wilke

1

en fait, le modèle ubuntu 12.04 openvz est maintenant public et ils ont fixé les autorisations aussi bien sur l'uraondm que sur le périphérique shm

— Le Shurrican
source

1

Le problème que udevtrigger n'a pas été démarré. Essayez de redémarrer avec /etc/init.d/udevtrigger restart... et si cela résout le problème comme pour moi ... alors changez le fichier /etc/init/udevtrigger.conf:

-     and not-container)
+     )

— Csabka
source

0

Dans RHEL: ajoutez des règles de sécurité avec des remplacements d'autorisations dans /etc/security/console.perms.d/

doit être similaire dans ubuntu

— GioMac
source