4 ms·

What's the security case for locking down /dev/random?

kazinator 12y ago
A security case for protecting a source of random bits is that they are important and that cryptographic applications and middleware can malfunction if these bits are not available. A world-readable /dev/random means that anyone can drain out random bits, making them unavailable to these applications. Someone somewhere could be setting up permissions in their Linux-based system based on this type of reasoning. It's a security regression if a character device can be suddenly accessed through a back-channel that ignores permissions.
- seabee 12y ago
  AFAIK isn't this the kind of thing SELinux can take care of? There needn't be any security regression with this change.
  - kzrdude 12y ago
    and seccomp
- clarry 12y ago
  If you don't trust a CSPRNG, then you pretty much might as well turn off all your crypto because you can't trust it. If you can trust a CSPRNG, then you should be able to trust urandom, as long as it's been properly initialized once. It won't drain out. It doesn't run out of bits. One application reading it doesn't make it unavailable for others. The same is true of the syscall.
  - seabee 12y ago
    /dev/random is a CSPRNG with finite output over a fixed time period, so it is susceptible to denial-of-service attacks.
    - tptacek 12y ago
      Which is why secure software doesn't use /dev/random, and prefers instead urandom.
      - binarycrusader 12y ago
        Maybe on Linux, but as I pointed out somewhere else; this doesn't apply to all *NIXes with a /dev/random or /dev/urandom: https://blogs.oracle.com/darren/entry/solaris_random_number_generation Short version is, on Solaris, you should use /dev/random for long-term keys and other high-value keying material. /dev/urandom should be used for everything else such as less demanding or shorter-term cryptographic uses like short-term session keys, paddings, and challenge strings.
        tptacek 12y ago
        I have two concerns with this comment: 1. It's not safe to use a weak RNG for session keys or even padding. Cryptosystems often fail catastrophically when their most obscure parameters are weak --- in fact, more exploitable cryptosystem flaws derive from issues like padding and IVs than keys. 2. FIPS 186-2 is a SHA-based DRBG. It doesn't "run out of entropy". What am I missing? The situation on Solaris w/r/t urandom appears to be identical to that of Linux.
        binarycrusader 12y ago
        1. The Solaris crypto designers / developers believe their rng is is appropriate for short-term session keys and padding. Read the post I linked before as to why the believe that. 2. /dev/random basically only uses bits from entropy sources while /dev/urandom just uses a few bits from /dev/random as a seed. Read the post I linked again. Again, I would reiterate, the situation is somewhat different for Solaris. Usage of /dev/random vs. /dev/urandom is actually considered different.
        tptacek 12y ago
        I read this post, both when you linked to it just now, and, prior to that, while I was researching the urandom blog post I wrote a few months ago. I'm being repetitive, but: * I think the distinction this post is drawing between Solaris random and urandom is functionally very similar to the distinction between Linux random and urandom (I think the distinction on Solaris might be that random has a higher quality rekeying system than urandom). * I can read a straightforward description of a SHA1 PRNG keyed by kernel entropy, which is what this blog post describes, and unless I'm missing something in the article, I don't see how it is any less cryptographically secure than Solaris /dev/random. It seems to be less forward-secure than /dev/random. That's about it. Since you appear to have grokked this article better than I did in either of the two cases I read it, could you give a short summary of the argument it presents for avoiding urandom for long-term secrets?
maccam94 12y ago
I think the concern is that a process could then exhaust all available entropy, and DOS any other processes depending on /dev/random. Currently, a chroot could protect against that.
- X-Istence 12y ago
  Yes, and it is exactly that chroot that is cause for concern and why this system call is being introduced...
- deleted 12y ago
  [deleted]
justincormack 12y ago
Consuming all the entropy. But its not a good argument. The BSDs manage and Linux has syscall controls.

A security case for protecting a source of random bits is that they are important and that cryptographic applications and middleware can malfunction if these bits are not available. A world-readable /dev/random means that anyone can drain out random bits, making them unavailable to these applications. Someone somewhere could be setting up permissions in their Linux-based system based on this type of reasoning. It's a security regression if a character device can be suddenly accessed through a back-channel that ignores permissions.

seabee 12y ago
AFAIK isn't this the kind of thing SELinux can take care of? There needn't be any security regression with this change.
- kzrdude 12y ago
  and seccomp
clarry 12y ago
If you don't trust a CSPRNG, then you pretty much might as well turn off all your crypto because you can't trust it. If you can trust a CSPRNG, then you should be able to trust urandom, as long as it's been properly initialized once. It won't drain out. It doesn't run out of bits. One application reading it doesn't make it unavailable for others. The same is true of the syscall.
- seabee 12y ago
  /dev/random is a CSPRNG with finite output over a fixed time period, so it is susceptible to denial-of-service attacks.
  - tptacek 12y ago
    Which is why secure software doesn't use /dev/random, and prefers instead urandom.
    - binarycrusader 12y ago
      Maybe on Linux, but as I pointed out somewhere else; this doesn't apply to all *NIXes with a /dev/random or /dev/urandom: https://blogs.oracle.com/darren/entry/solaris_random_number_generation Short version is, on Solaris, you should use /dev/random for long-term keys and other high-value keying material. /dev/urandom should be used for everything else such as less demanding or shorter-term cryptographic uses like short-term session keys, paddings, and challenge strings.
      - tptacek 12y ago
        I have two concerns with this comment: 1. It's not safe to use a weak RNG for session keys or even padding. Cryptosystems often fail catastrophically when their most obscure parameters are weak --- in fact, more exploitable cryptosystem flaws derive from issues like padding and IVs than keys. 2. FIPS 186-2 is a SHA-based DRBG. It doesn't "run out of entropy". What am I missing? The situation on Solaris w/r/t urandom appears to be identical to that of Linux.
        binarycrusader 12y ago
        1. The Solaris crypto designers / developers believe their rng is is appropriate for short-term session keys and padding. Read the post I linked before as to why the believe that. 2. /dev/random basically only uses bits from entropy sources while /dev/urandom just uses a few bits from /dev/random as a seed. Read the post I linked again. Again, I would reiterate, the situation is somewhat different for Solaris. Usage of /dev/random vs. /dev/urandom is actually considered different.
        tptacek 12y ago
        I read this post, both when you linked to it just now, and, prior to that, while I was researching the urandom blog post I wrote a few months ago. I'm being repetitive, but: * I think the distinction this post is drawing between Solaris random and urandom is functionally very similar to the distinction between Linux random and urandom (I think the distinction on Solaris might be that random has a higher quality rekeying system than urandom). * I can read a straightforward description of a SHA1 PRNG keyed by kernel entropy, which is what this blog post describes, and unless I'm missing something in the article, I don't see how it is any less cryptographically secure than Solaris /dev/random. It seems to be less forward-secure than /dev/random. That's about it. Since you appear to have grokked this article better than I did in either of the two cases I read it, could you give a short summary of the argument it presents for avoiding urandom for long-term secrets?

maccam94 12y ago

I think the concern is that a process could then exhaust all available entropy, and DOS any other processes depending on /dev/random. Currently, a chroot could protect against that.

X-Istence 12y ago
Yes, and it is exactly that chroot that is cause for concern and why this system call is being introduced...
deleted 12y ago
[deleted]

justincormack 12y ago

Consuming all the entropy. But its not a good argument. The BSDs manage and Linux has syscall controls.