¿Por qué / dev / urandom solo es legible por root desde Ubuntu 12.04 y cómo puedo "arreglarlo"?


10

Solía ​​trabajar con plantillas Ubuntu 10.04 en muchos servidores. Desde que cambié a 12.04 tengo problemas que ahora he aislado.

El dispositivo / dev / urandom solo es accesible para root.

Esto causó que los motores SSL, al menos en PHP, por ejemplo file_get_contents (https: // ... fallaran.

También rompió la mina roja.

Después de un chmod 644 funciona bien, pero eso no se queda al reiniciar.

Entonces mi pregunta.

  1. ¿Por qué es esto? No veo ningún riesgo de seguridad porque ... quiero decir ... ¿quieres robar algunos datos aleatorios?

  2. ¿Cómo puedo arreglarlo? Los servidores están aislados y son utilizados por una sola aplicación, por eso uso openvz. Pienso en algo así como un script de nivel de ejecución más o menos ... pero ¿cómo lo hago de manera eficiente? Maby con dpkg o apt?

  3. Lo mismo ocurre con vor / dev / shm. en este caso entiendo totalmente por qué no es accesible, pero supongo que puedo "arreglarlo" de la misma manera para arreglar / dev / urandom


¿Qué ls -l /dev/urandommuestra antes de cambiar los permisos? ¿Personalizó alguno /etc/udev/rules.d o /lib/udev/rules.darchivos?
David Schwartz

root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom- No configuré nada, este es un servidor virgen simple, ni siquiera se ejecutó la actualización de apt-get.
The Shurrican

3
La documentación dice específicamente que los permisos deberían ser 0644. La pregunta es: ¿por qué no lo son?
David Schwartz

1
FWIW, en mi Precise recién instalado, / dev / urandom es 0666. Durante la instalación, elegí "servidor openssh" como la única opción de rol. Quizás algún paquete en su configuración haga algo tonto.
cjc

estoy de acuerdo. mis reglas de udev también dicen que debería ser. Creo que tiene algo que ver con la virtualización.
The Shurrican

Respuestas:


3

Con una lectura excesiva de udev, puede drenar el grupo aleatorio, lo que resulta en números aleatorios predecibles. Probablemente esta es la razón por la cual / dev / urandom no está disponible para leer para todos. (eliminado porque Graeme Donaldson tiene razón)

En caso de que aún desee cambiar el permiso, consulte las reglas de udev responsables de configurar los modos en / dev / urandom, en lugar de desordenar sus scripts de inicio.

Bajo Debian, es fácil encontrar la regla de culpabilidad:

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

En su caso, MODE definitivamente no es 0666.

Cámbielo según las reglas de configuración de udev, si lo desea.

Nota: http://lists.centos.org/pipermail/centos/2009-July/079134.html podría ayudar a cambiar udev.

Básicamente, necesitará crear una regla con un aspecto similar al resultado grep, excepto que tiene un modo correcto configurado y agregarlo como un archivo de reglas en /etc/udev/rules.d/ (tenga en cuenta las posibles diferencias en Ubuntu y Debian !)


Si / dev / urandom solo es legible por root, entonces OpenSSH y el software que se vincula con OpenSSL, GnuTLS y otras bibliotecas de criptografía tendrían que ejecutarse como root o iniciarse como root y luego abandonar los privilegios. De alguna manera eso suena mucho peor.
Gerald Combs

3
/ dev / urandom no se basa en el grupo de entropía. Solo las lecturas de / dev / random provocan el agotamiento del grupo de entropía.
ThatGraemeGuy

Gerald: sshd comienza como root. Por ejemplo, para vincular el puerto 22 y suid al usuario conectado, 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 de julio 2 12:39 / dev / urandom realmente no parece una configuración incorrecta sino un error, sin embargo, ¡está corregido en la nueva plantilla de instalación de openvz!
The Shurrican

@ThatGraemeGuy Me doy cuenta de que llego tarde a la fiesta, pero eso no es del todo correcto. /dev/random bloquea cuando la estimación de entropía es baja, mientras /dev/urandomcontinúa produciendo números pseudoaleatorios incluso cuando la estimación de entropía es baja. Dicho esto, el concepto completo de la agrupación de entropía de alguna manera "quedarse sin aleatoriedad" es engañoso y sin sentido .
Stephen Touset

1

En cuanto a cómo puede solucionarlo, una curita temporal sería solo

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

que intenté pero no funcionó. ahora agregué el comando chmod justo al final de /etc/rc0.d/S30urandom ... eso funcionó
The Shurrican

Hay algunos problemas que pueden hacer que /etc/rc.local no se obtenga correctamente en Ubuntu, incluido su permiso (debe marcarse como ejecutable). ver aquí: bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/882254
michel-slm

Parecía prometedor pero no ayuda. también parece que el rc.local no se ejecuta, intenté escribir un archivo simple en tmp pero tampoco funcionó. Los permisos son correctos. Intenté ejecutar solo para root, leer en reposo y también 777 ...
The Shurrican

2
Dado que la solución es probablemente específica de Ubuntu, AskUbuntu es probablemente una mejor apuesta en este momento. Estoy felizmente usando systemd, y /etc/rc.d/rc.local simplemente funciona sin fallas como lo hizo en initscripts de systemV: /
michel-slm

Tenga en cuenta que debe editar el /etc/rc.localarchivo. En mi caso (Ubuntu 16.04), el archivo terminó con la salida 0, por lo que si solo agrega una línea, de hecho no funcionaría.
Alexis Wilke

1

en realidad, la plantilla openvz ubuntu 12.04 ahora es pública y arreglaron los permisos tanto en el uraondm como en el dispositivo shm


1

El problema de que udevtrigger no se ha iniciado. Intente reiniciar con /etc/init.d/udevtrigger restart... y si resuelve el problema en cuanto a mí ... cambie el archivo /etc/init/udevtrigger.conf:

-     and not-container)
+     )

0

En RHEL: agregue reglas de seguridad con anulaciones de permisos en /etc/security/console.perms.d/

debe ser similar en ubuntu

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.