Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 10 down vote favorite
1

I used to work with Ubuntu 10.04 templates on a lot of servers. Since changing to 12.04 I have problems that I've now isolated.

The /dev/urandom device is only accessible to root.

This caused SSL engines, at least in PHP, for example file_get_contents(https://... to fail.

It also broke redmine.

After a chmod 644 it works fine, but that doesnt stay upon reboot.

So my question.

  1. why is this? I see no security risk because... i mean.. wanna steal some random data?

  2. How can I "fix" it? The servers are isolated and used by only one application, thats why I use openvz. I think about something like a runlevel script or so... but how do I do it efficiently? Maby with dpkg or apt?

  3. The same goes vor /dev/shm. in this case i totally understand why its not accessible, but I assume I can "fix" it the same way to fix /dev/urandom

share|improve this question
What does ls -l /dev/urandom show before you change the permissions? Did you customize any /etc/udev/rules.d or /lib/udev/rules.d files? – David Schwartz May 22 '12 at 10:58
root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom - i didnt set anything, this is a plain virgin server, not even apt-get update ran yet. – The Shurrican May 22 '12 at 11:07
3  
The documentation specifically says the permissions should be 0644. The question is -- why aren't they?! – David Schwartz May 22 '12 at 11:10
1  
FWIW, on my freshly installed Precise, /dev/urandom is 0666. During the install, I chose "openssh server" as the only role option. Perhaps some package in your setup does something dumb. – cjc May 22 '12 at 11:41
i agree. my udev rules also say it should be. i think it has something to do with the virtualization. – The Shurrican May 22 '12 at 12:33
show 1 more comment

5 Answers

up vote 2 down vote

With excessive reading from udev, you can drain the random pool, resulting in predictable random numbers. Probably this is the reason why /dev/urandom is not available to read for everyone. (deleted because Graeme Donaldson is right)

In case you'd still like to change the permission,look into the udev rules responsible for setting modes on /dev/urandom, instead of messing up your init scripts.

Under Debian, it's easy to find the guilty rule:

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

In your case, MODE is definitely not 0666.

Change it according udev configuration rules, if you wish.

Note: http://lists.centos.org/pipermail/centos/2009-July/079134.html might help with changing udev.

You'll basically need to create a rule with looks like the grep result, except that is has a correct mode set, and add it as a rulefile in /etc/udev/rules.d/ (mind the possible differences in Ubuntu and Debian!)

share|improve this answer
If /dev/urandom is only readable by root then OpenSSH and software that links with OpenSSL, GnuTLS and other cryptography libraries would have to either run as root or start up as root then drop privileges. Somehow that sounds much worse. – Gerald Combs Jun 20 '12 at 20:56
2  
/dev/urandom does not rely on the entropy pool. Only reads from /dev/random causes depletion of the entropy pool. – ThatGraemeGuy Jun 20 '12 at 20:58
Gerald: sshd starts as root. For example, to bind port 22 and to suid to the logged in user, etc. – asdmin Jun 21 '12 at 8:41
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 it really looks like no misconfiguration but a bug, however it is fixed in the new openvz installation template! – The Shurrican Jul 2 '12 at 9:04
up vote 1 down vote

The problem that udevtrigger hasn't been started. Try to restart with /etc/init.d/udevtrigger restart... and if it solve the problem as for me... then change /etc/init/udevtrigger.conf file:

-     and not-container)
+     )
share|improve this answer
up vote 0 down vote

As for how you can fix it, a temporary band-aid would be to just

cat "chmod 666 /dev/urandom" >> /etc/rc.local
share|improve this answer
that i tried but didnt work. now i added the chmod command just to the bottom of /etc/rc0.d/S30urandom ... that worked – The Shurrican Jun 1 '12 at 13:22
There are some issues that might cause /etc/rc.local to not be sourced properly on Ubuntu -- including its permission (it has to be marked executable). see here: bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/882254 – hircus Jun 1 '12 at 16:45
looked promising but doesnt help. also the rc.local doesnt seem to get executed, i tried to write a simple file to tmp but that didnt work too. the permissions are correct. i tried with execute for root only, rest read and also 777... – The Shurrican Jun 3 '12 at 8:43
1  
since the solution is likely Ubuntu-specific, AskUbuntu is probably a better bet at this point. I'm blissfully using systemd, and /etc/rc.d/rc.local just works without a glitch as it did under systemV initscripts :/ – hircus Jun 3 '12 at 15:39
up vote 0 down vote

In RHEL: add security rules with permission overrides in /etc/security/console.perms.d/

must be similar in ubuntu

share|improve this answer
up vote 0 down vote

actually the ubuntu 12.04 openvz template is now public and they fixed the permissions as well on the uraondm as on the shm device

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.