Perché / dev / urandom è leggibile solo da root da Ubuntu 12.04 e come posso "ripararlo"?

10

Lavoravo con i modelli Ubuntu 10.04 su molti server. Da quando sono passato al 12.04 ho problemi che ora ho isolato.

Il dispositivo / dev / urandom è accessibile solo da root.

Ciò ha causato il fallimento dei motori SSL, almeno in PHP, ad esempio file_get_contents (https: // ...

Ha anche rotto la miniera rossa.

Dopo un chmod 644 funziona bene, ma questo non rimane al riavvio.

Quindi la mia domanda.

perchè è questo? Non vedo rischi per la sicurezza perché ... voglio dire ... vuoi rubare dei dati casuali?
Come posso "ripararlo"? I server sono isolati e utilizzati da una sola applicazione, ecco perché uso openvz. Penso a qualcosa come uno script runlevel o giù di lì ... ma come lo faccio in modo efficiente? Maby con dpkg o apt?
Lo stesso vale vor / dev / shm. in questo caso capisco perfettamente perché non è accessibile, ma presumo di poterlo "risolvere" allo stesso modo per correggere / dev / urandom

— The Shurrican
fonte

Cosa ls -l /dev/urandommostra prima di modificare le autorizzazioni? Hai personalizzato qualcuno /etc/udev/rules.d o /lib/udev/rules.dfile?

— David Schwartz,

root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom- Non ho impostato nulla, questo è un semplice server vergine, nemmeno apt-get update è stato ancora eseguito.

— Lo Shurrican

3

La documentazione specifica che le autorizzazioni dovrebbero essere 0644. La domanda è: perché non lo sono ?!

— David Schwartz,

1

FWIW, sul mio Precise appena installato, / dev / urandom è 0666. Durante l'installazione, ho scelto "openssh server" come unica opzione di ruolo. Forse un pacchetto nel tuo setup fa qualcosa di stupido.

— cjc,

sono d'accordo. le mie regole udev dicono anche che dovrebbe essere. penso che abbia qualcosa a che fare con la virtualizzazione.

— Lo Shurrican

3

Con una lettura eccessiva da udev, è possibile svuotare il pool casuale, ottenendo numeri casuali prevedibili. Probabilmente questo è il motivo per cui / dev / urandom non è disponibile per la lettura per tutti. (cancellato perché Graeme Donaldson ha ragione)

Nel caso in cui desideri ancora cambiare l'autorizzazione, guarda le regole di udev responsabili di impostare le modalità su / dev / urandom, invece di rovinare i tuoi script di init.

Sotto Debian, è facile trovare la regola del colpevole:

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

Nel tuo caso, MODE non è sicuramente 0666.

Modificalo secondo le regole di configurazione di udev, se lo desideri.

Nota: http://lists.centos.org/pipermail/centos/2009-July/079134.html potrebbe aiutare a cambiare udev.

Fondamentalmente dovrai creare una regola con l'aspetto del risultato grep, tranne per il fatto che ha una modalità impostata corretta e aggiungerla come file di regole in /etc/udev/rules.d/ (attenzione alle possibili differenze in Ubuntu e Debian !)

— asdmin
fonte

Se / dev / urandom è leggibile solo da root, allora OpenSSH e il software che si collega a OpenSSL, GnuTLS e altre librerie di crittografia dovrebbero essere eseguiti come root o avviarsi come root quindi rilasciare i privilegi. In qualche modo suona molto peggio.

— Gerald Combs,

3

/ dev / urandom non si basa sul pool di entropia. Legge solo da / dev / random provoca l'esaurimento del pool di entropia.

— ThatGraemeGuy

Gerald: sshd inizia come root. Ad esempio, per associare la porta 22 e per fare richiesta all'utente che ha effettuato l'accesso, ecc.

— 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 lug 2 12:39 / dev / urandom sembra davvero nessuna configurazione errata ma un bug, tuttavia è stato corretto nel nuovo modello di installazione di openvz!

— Lo Shurrican il

@ThatGraemeGuy Mi rendo conto di essere in ritardo alla festa, ma non è del tutto corretto. /dev/random si blocca quando la stima dell'entropia è bassa, mentre /dev/urandomcontinua a produrre numeri pseudocasuali anche quando la stima dell'entropia è bassa. Detto questo, l'intero concetto del pool di entropia in qualche modo "a corto di casualità" è fuorviante e insignificante .

— Stephen Touset,

1

Per quanto riguarda il modo in cui puoi risolverlo, un cerotto temporaneo sarebbe solo

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

— Michel-SLM
fonte

che ho provato ma non ha funzionato. ora ho aggiunto il comando chmod proprio in fondo a /etc/rc0.d/S30urandom ... che ha funzionato

— The Shurrican

Ci sono alcuni problemi che potrebbero impedire a /etc/rc.local di non provenire correttamente su Ubuntu - inclusa la sua autorizzazione (deve essere contrassegnato come eseguibile). vedi qui: bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/882254

— michel-slm

sembrava promettente ma non aiuta. anche rc.local sembra non essere eseguito, ho provato a scrivere un semplice file su tmp ma anche quello non ha funzionato. le autorizzazioni sono corrette. ho provato con esegui solo per root, resto a leggere e anche 777 ...

— The Shurrican

2

poiché la soluzione è probabilmente specifica per Ubuntu, AskUbuntu è probabilmente una scommessa migliore a questo punto. Sto usando beatamente systemd, e /etc/rc.d/rc.local funziona senza problemi come ha fatto con gli script di sistema systemV: /

— michel-slm

Si noti che è necessario modificare il /etc/rc.localfile. Nel mio caso (Ubuntu 16.04), il file si è concluso con l'uscita 0, quindi se si aggiunge semplicemente una riga, in effetti non funzionerebbe.

— Alexis Wilke,

1

in realtà il modello Ubuntu 12.04 openvz è ora pubblico e hanno riparato le autorizzazioni sia su uraondm che sul dispositivo shm

— The Shurrican
fonte

1

Il problema che udevtrigger non è stato avviato. Prova a riavviare con /etc/init.d/udevtrigger restart... e se risolve il problema come per me ... quindi modifica il file /etc/init/udevtrigger.conf:

-     and not-container)
+     )

— Csabka
fonte

0

In RHEL: aggiungi le regole di sicurezza con le autorizzazioni di sovrascrittura in /etc/security/console.perms.d/

deve essere simile in Ubuntu

— GioMac
fonte