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


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 que par root.

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

Il a également cassé la mine rouge.

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

Donc ma question.

  1. 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?

  2. 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, etc., mais comment le faire efficacement? Maby avec dpkg ou apt?

  3. La même chose va vor / dev / shm. dans ce cas, je comprends tout à fait pourquoi ce n'est pas accessible, mais je suppose que je peux le "réparer" de la même manière pour réparer / dev / urandom


10
2018-05-22 10:50


origine


Qu'est-ce que ls -l /dev/urandom montrer avant de changer les permissions? Avez-vous personnaliser tout  /etc/udev/rules.d ou /lib/udev/rules.d des dossiers? - David Schwartz
root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom - Je n'ai rien mis, c'est un serveur vierge, même pas apt-get update a couru pour le moment. - The Shurrican
le Documentation dit spécifiquement que les autorisations doivent être 0644. La question est - pourquoi ne sont-ils pas?! - David Schwartz
FWIW, sur mon Precise fraîchement installé, / dev / urandom est 0666. Au cours de l’installation, j’ai choisi «serveur OpenSh» comme seule option. Peut-être qu'un paquet dans votre configuration fait quelque chose de stupide. - cjc
je suis d'accord. mes règles de udev disent aussi que cela devrait être. Je pense que cela a quelque chose à voir avec la virtualisation. - The Shurrican


Réponses:


Avec une lecture excessive de udev, vous pouvez vider le pool aléatoire, ce qui génère des nombres aléatoires prévisibles. C'est probablement la raison pour laquelle / dev / urandom n'est pas disponible pour tout le monde. (supprimé parce que Graeme Donaldson a raison)

Si vous souhaitez toujours modifier l'autorisation, consultez 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 de culpabilité:

$ 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 en fonction des règles de configuration d'udev, si vous le souhaitez.

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

En gros, vous aurez besoin de créer une règle ressemblant au résultat de grep, sauf que le jeu de mode est correct, et de l’ajouter comme fichier de règle dans /etc/udev/rules.d/ (attention aux différences possibles entre Ubuntu et Debian. !)


3
2018-06-20 15:50



Si / dev / urandom est uniquement lisible par root, OpenSSH et les logiciels liés à OpenSSL, GnuTLS et d’autres bibliothèques de cryptographie devront soit s’exécuter en tant que root, soit se lancer en tant que root, puis supprimer les privilèges. D'une certaine manière ça sonne beaucoup pire. - Gerald Combs
/ dev / urandom ne dépend pas du pool d'entropie. Seules les lectures de / dev / random entraînent l'épuisement du pool d'entropie. - ThatGraemeGuy
Gerald: sshd commence en tant que root. Par exemple, pour lier le port 22 et indiquer le nom de 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 "racine @ redmine: ~ # ls -lha / dev / urandom crw ------- 1 racine 1, 9 juillet 2 12:39 / dev / urandom, cela ne ressemble vraiment à aucune configuration erronée, mais à un bogue, mais il est corrigé dans le nouveau modèle d'installation openvz! - The Shurrican
@ThatGraemeGuy Je réalise que je suis en retard à la fête, mais ce n'est pas tout à fait correct. /dev/random  des blocs lorsque l'estimation d'entropie est faible, alors que /dev/urandom continue à produire des nombres pseudo-aléatoires même lorsque l'estimation d'entropie est faible. Cela dit, le concept entier du pool d'entropie est en quelque sorte "épuisé". trompeuse et dénuée de sens. - Stephen Touset


Pour ce qui est de la solution, un pansement temporaire consisterait simplement à:

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

1
2018-05-30 02:20



que j'ai essayé mais n'a pas fonctionné. Maintenant, j'ai ajouté la commande chmod juste au 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 se trouver correctement dans Ubuntu - y compris son autorisation (il doit être marqué comme exécutable). vois ici: bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/882254 - michel-slm
avait l'air prometteur mais ne m'aide pas. aussi le rc.local ne semble pas être exécuté, j'ai essayé d'écrire un fichier simple à tmp mais cela n'a pas fonctionné aussi. les autorisations sont correctes. j'ai essayé avec execute pour root seulement, reste en lecture et aussi 777 ... - The Shurrican
Puisque la solution est probablement spécifique à Ubuntu, AskUbuntu est probablement un meilleur choix à ce stade. J'utilise à merveille systemd et /etc/rc.d/rc.local fonctionne sans problème, comme c'était le cas dans les scripts systèmeV: / - michel-slm
Notez que vous devez éditer le /etc/rc.local fichier. Dans mon cas (Ubuntu 16.04), le fichier s’est terminé par la sortie 0; si vous ajoutez simplement une ligne, cela ne fonctionnera pas. - Alexis Wilke


En fait, le modèle openvz ubuntu 12.04 est maintenant public et ils ont corrigé les autorisations aussi bien sur le périphérique que sur le périphérique shm.


1
2018-06-20 19:24





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)
+     )

1
2017-09-12 07:17





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

doit être similaire à Ubuntu


0
2018-06-13 13:32