[PATCH] random: add blocking facility to urandom
Certain security-related certifications and their respective review
bodies have said that they find use of /dev/urandom for certain
functions, such as setting up ssh connections, is acceptable, but if and
only if /dev/urandom can block after a certain threshold of bytes have
been read from it with the entropy pool exhausted. Initially, we were
investigating increasing entropy pool contributions, so that we could
simply use /dev/random, but since that hasn't (yet) panned out, and
upwards of five minutes to establsh an ssh connection using an
entropy-starved /dev/random is unacceptable, we started looking at the
blocking urandom approach.
At present, urandom never blocks, even after all entropy has been
exhausted from the entropy input pool. random immediately blocks when
the input pool is exhausted. Some use cases want behavior somewhere in
between these two, where blocking only occurs after some number have
bytes have been read following input pool entropy exhaustion. Its
possible to accomplish this and make it fully user-tunable, by adding a
sysctl to set a max-bytes-after-0-entropy read threshold for urandom. In
the out-of-the-box configuration, urandom behaves as it always has, but
with a threshold value set, we'll block when its been exceeded.
Tested by dd'ing from /dev/urandom in one window, and starting/stopping
a cat of /dev/random in the other, with some debug spew added to the
urandom read function to verify functionality.
CC: Matt Mackall m...@selenic.com
CC: Neil Horman nhor...@redhat.com
CC: Herbert Xu herbert...@redhat.com
CC: Steve Grubb sgr...@redhat.com
CC: Stephan Mueller stephan.muel...@atsec.com
CC: lkml linux-ker...@vger.kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
Resending, neglected to cc lkml the first time, and this change could
have implications outside just the crypto layer...
drivers/char/random.c | 82 -
1 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c35a785..cf48b0f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -289,6 +289,13 @@ static int trickle_thresh __read_mostly = INPUT_POOL_WORDS
* 28;
static DEFINE_PER_CPU(int, trickle_count);
/*
+ * In normal operation, urandom never blocks, but optionally, you can
+ * set urandom to block after urandom_block_thresh bytes are read with
+ * the entropy pool exhausted.
+ */
+static int urandom_block_thresh = 0;
+
+/*
* A pool of size .poolwords is stirred with a primitive polynomial
* of degree .poolwords over GF(2). The taps for various sizes are
* defined below. They are chosen to be evenly spaced (minimum RMS
@@ -383,6 +390,7 @@ static struct poolinfo {
* Static global variables
*/
static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
+static DECLARE_WAIT_QUEUE_HEAD(urandom_read_wait);
static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
static struct fasync_struct *fasync;
@@ -554,6 +562,7 @@ static void credit_entropy_bits(struct entropy_store *r,
int nbits)
/* should we wake readers? */
if (r == input_pool entropy_count = random_read_wakeup_thresh) {
wake_up_interruptible(random_read_wait);
+ wake_up_interruptible(urandom_read_wait);
kill_fasync(fasync, SIGIO, POLL_IN);
}
spin_unlock_irqrestore(r-lock, flags);
@@ -1060,7 +1069,55 @@ random_read(struct file *file, char __user *buf, size_t
nbytes, loff_t *ppos)
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
- return extract_entropy_user(nonblocking_pool, buf, nbytes);
+ ssize_t n;
+ static int excess_bytes_read;
+
+ /* this is the default case with no urandom blocking threshold set */
+ if (!urandom_block_thresh)
+ return extract_entropy_user(nonblocking_pool, buf, nbytes);
+
+ if (nbytes == 0)
+ return 0;
+
+ DEBUG_ENT(reading %d bits\n, nbytes*8);
+
+ /* urandom blocking threshold set, but we have sufficient entropy */
+ if (input_pool.entropy_count = random_read_wakeup_thresh) {
+ excess_bytes_read = 0;
+ return extract_entropy_user(nonblocking_pool, buf, nbytes);
+ }
+
+ /* low on entropy, start counting bytes read */
+ if (excess_bytes_read + nbytes urandom_block_thresh) {
+ n = extract_entropy_user(nonblocking_pool, buf, nbytes);
+ excess_bytes_read += n;
+ return n;
+ }
+
+ /* low entropy read threshold exceeded, now we have to block */
+ n = nbytes;
+ if (n SEC_XFER_SIZE)
+ n = SEC_XFER_SIZE;
+
+ n = extract_entropy_user(nonblocking_pool, buf, n);
+ excess_bytes_read += n;
+
+ if (file-f_flags O_NONBLOCK)
+ return -EAGAIN;
+
+ DEBUG_ENT(sleeping?\n);
+
+ wait_event_interruptible(urandom_read_wait,
+
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote: Certain security-related certifications and their respective review bodies have said that they find use of /dev/urandom for certain functions, such as setting up ssh connections, is acceptable, but if and only if /dev/urandom can block after a certain threshold of bytes have been read from it with the entropy pool exhausted. Initially, we were investigating increasing entropy pool contributions, so that we could simply use /dev/random, but since that hasn't (yet) panned out, and upwards of five minutes to establsh an ssh connection using an entropy-starved /dev/random is unacceptable, we started looking at the blocking urandom approach. Can't you accomplish this in userspace by trying to read as much as you can out of /dev/random without blocking, then reading out of /dev/urandom the minimum between allowed threshold and remaining bytes, and then blocking on /dev/random? For example, lets say you need 100 bytes of randomness, and your threshold is 30 bytes. You try reading out of /dev/random and get 50 bytes, at that point you'll read another 30 (=threshold) bytes out /dev/urandom and then you'll need to block on /dev/random until you get the remaining 20 bytes. -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
Sasha Levin wrote: On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote: Certain security-related certifications and their respective review bodies have said that they find use of /dev/urandom for certain functions, such as setting up ssh connections, is acceptable, but if and only if /dev/urandom can block after a certain threshold of bytes have been read from it with the entropy pool exhausted. Initially, we were investigating increasing entropy pool contributions, so that we could simply use /dev/random, but since that hasn't (yet) panned out, and upwards of five minutes to establsh an ssh connection using an entropy-starved /dev/random is unacceptable, we started looking at the blocking urandom approach. Can't you accomplish this in userspace by trying to read as much as you can out of /dev/random without blocking, then reading out of /dev/urandom the minimum between allowed threshold and remaining bytes, and then blocking on /dev/random? For example, lets say you need 100 bytes of randomness, and your threshold is 30 bytes. You try reading out of /dev/random and get 50 bytes, at that point you'll read another 30 (=threshold) bytes out /dev/urandom and then you'll need to block on /dev/random until you get the remaining 20 bytes. We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote: Sasha Levin wrote: On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote: Certain security-related certifications and their respective review bodies have said that they find use of /dev/urandom for certain functions, such as setting up ssh connections, is acceptable, but if and only if /dev/urandom can block after a certain threshold of bytes have been read from it with the entropy pool exhausted. Initially, we were investigating increasing entropy pool contributions, so that we could simply use /dev/random, but since that hasn't (yet) panned out, and upwards of five minutes to establsh an ssh connection using an entropy-starved /dev/random is unacceptable, we started looking at the blocking urandom approach. Can't you accomplish this in userspace by trying to read as much as you can out of /dev/random without blocking, then reading out of /dev/urandom the minimum between allowed threshold and remaining bytes, and then blocking on /dev/random? For example, lets say you need 100 bytes of randomness, and your threshold is 30 bytes. You try reading out of /dev/random and get 50 bytes, at that point you'll read another 30 (=threshold) bytes out /dev/urandom and then you'll need to block on /dev/random until you get the remaining 20 bytes. We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. [...] A flip-side here is that you're going to break every piece of userspace which assumed (correctly) that /dev/urandom never blocks. Since this is a sysctl you can't fine tune which processes/threads/file-handles will block on /dev/urandom and which ones won't. [..] And anything done in userspace is going to be full of possible holes [..] Such as? Is there an example of a case which can't be handled in userspace? [..] there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Does the weak entropy you get out of /dev/urandom get weaker the more you pull out of it? I assumed that this change is done because you want to limit the amount of weak entropy mixed in with strong entropy. btw, Is the threshold based on a research done on the linux RNG? Or is it an arbitrary number that would be set by your local sysadmin? -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
Sasha Levin wrote: On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote: Sasha Levin wrote: On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote: Certain security-related certifications and their respective review bodies have said that they find use of /dev/urandom for certain functions, such as setting up ssh connections, is acceptable, but if and only if /dev/urandom can block after a certain threshold of bytes have been read from it with the entropy pool exhausted. Initially, we were investigating increasing entropy pool contributions, so that we could simply use /dev/random, but since that hasn't (yet) panned out, and upwards of five minutes to establsh an ssh connection using an entropy-starved /dev/random is unacceptable, we started looking at the blocking urandom approach. Can't you accomplish this in userspace by trying to read as much as you can out of /dev/random without blocking, then reading out of /dev/urandom the minimum between allowed threshold and remaining bytes, and then blocking on /dev/random? For example, lets say you need 100 bytes of randomness, and your threshold is 30 bytes. You try reading out of /dev/random and get 50 bytes, at that point you'll read another 30 (=threshold) bytes out /dev/urandom and then you'll need to block on /dev/random until you get the remaining 20 bytes. We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. [...] A flip-side here is that you're going to break every piece of userspace which assumed (correctly) that /dev/urandom never blocks. Out of the box, that continues to be the case. This just adds a knob so that it *can* block at a desired threshold. Since this is a sysctl you can't fine tune which processes/threads/file-handles will block on /dev/urandom and which ones won't. The security requirement is that everything blocks. [..] And anything done in userspace is going to be full of possible holes [..] Such as? Is there an example of a case which can't be handled in userspace? How do you mandate preventing reads from urandom when there isn't sufficient entropy? You likely wind up needing to restrict access to the actual urandom via permissions and selinux policy or similar, and then run a daemon or something that provides a pseudo-urandom that brokers access to the real urandom. Get the permissions or policy wrong, and havoc ensues. An issue with the initscript or udev rule to hide the real urandom, and things can fall down. Its a whole lot more fragile than this approach, and a lot more involved in setting it up. [..] there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Does the weak entropy you get out of /dev/urandom get weaker the more you pull out of it? I assumed that this change is done because you want to limit the amount of weak entropy mixed in with strong entropy. The argument is that once there's no entropy left, an attacker only needs X number of samples before they can start accurately determining what the next random number will be. btw, Is the threshold based on a research done on the linux RNG? Or is it an arbitrary number that would be set by your local sysadmin? Stephan (cc'd on the thread) is attempting to get some feedback from BSI as to what they have in the way of an actual number. The implementation has a goal of being flexible enough for whatever a given certification or security requirement says that number is. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. But only if you've set the sysctl to a non-zero value, and even then, only if someone is actively draining entropy from /dev/random. Otherwise, in practice, it behaves the same as always. Granted, I haven't tested with all possible userspace to see how it might fall down, but suggestions for progs to try would be welcomed. But again, I want to stress that out of the box, there's absolutely no change to the way urandom behaves, no blocking, this *only* kicks in if you twiddle the sysctl because you have some sort of security requirement that mandates it. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
From: Ted Ts'o ty...@mit.edu Date: Wed, 7 Sep 2011 15:27:37 -0400 On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. Agreed, and this is a really poor approach to solving the problem. If you change semantics, you have to create a new facility and then convert the userland pieces over to it. Yes, this is harder and requires more work, but it is necessary as it is the only way to ensure that we won't break something. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 15:30 -0400, Jarod Wilson wrote: Sasha Levin wrote: On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote: Sasha Levin wrote: [..] And anything done in userspace is going to be full of possible holes [..] Such as? Is there an example of a case which can't be handled in userspace? How do you mandate preventing reads from urandom when there isn't sufficient entropy? You likely wind up needing to restrict access to the actual urandom via permissions and selinux policy or similar, and then run a daemon or something that provides a pseudo-urandom that brokers access to the real urandom. Get the permissions or policy wrong, and havoc ensues. An issue with the initscript or udev rule to hide the real urandom, and things can fall down. Its a whole lot more fragile than this approach, and a lot more involved in setting it up. Replace /dev/urandom with a simple CUSE driver, redirect reads to the real urandom after applying your threshold. -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2.0 0/3] evm: digital signature verification extension
Hello Dmitry, Was there supposed to be part 1/3 for this patch set. At least I didn't see it also it doesn't show in mailing list archives. I also don't see it in mailing list archives at http://marc.info/?l=linux-security-moduler=1b=201109w=2 Can you resend it? -Sam -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. When a system is underattack, do you really want to be using a PRNG for anything like seeding openssl? Because a PRNG is what urandom degrades into when its attacked. If enough bytes are read that an attacker can guess the internal state of the RNG, do you really want it seeding a openssh session? At that point you really need it to stop momentarily until it gets fresh entropy so the internal state is unknown. That's what this is really about. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of Theres no way you can guarantee that. A quick lsof on my system here shows 27 unique pids that are holding /dev/urandom open, and while they may all be small reads, taken in aggregate, I can imagine that they could pull a significant amount of entropy out of /dev/urandom. things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. How can you be sure of that? This seems to make assumptions about both the rate at which entropy is drained from /dev/urandom and the limit at which you will start blocking, neither of which you can be sure of. When a system is underattack, do you really want to be using a PRNG for anything like How can you be sure that this only happens when a system is under some sort of attack. /dev/urandom is there for user space to use, and we can't make assumptions as to how it will get drawn from. What if someone was running some monte-carlo based test program? That could completely exhaust the entropy in /dev/urandom and would be perfectly legitimate. seeding openssl? Because a PRNG is what urandom degrades into when its attacked. If enough bytes are read that an attacker can guess the internal state of the RNG, do you really want it seeding a openssh session? At that point you really need it to stop momentarily until it gets fresh entropy so the internal state is unknown. That's what this is really about. I never really want my ssh session to be be seeded with non-random data. Of course, in my mind thats an argument for making ssh use /dev/random rather than /dev/urandom, but I'm willing to take the tradeoff in speed most of the time. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. I thought you need to feed random, not urandom. Anyway, it won't happen fast enough to actually not block. Writing 1TB of urandom into a disk won't generate 1TB (or anything close to that) of randomness to cover for itself. Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparation_and_mapping -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 04:33:05 PM Neil Horman wrote: On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of Theres no way you can guarantee that. A quick lsof on my system here shows 27 unique pids that are holding /dev/urandom open, and while they may all be small reads, taken in aggregate, I can imagine that they could pull a significant amount of entropy out of /dev/urandom. These are likely for reseeding purposes. Even openssl/libgcrypt/nss need reseeding. things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. How can you be sure of that? This seems to make assumptions about both the rate at which entropy is drained from /dev/urandom and the limit at which you will start blocking, neither of which you can be sure of. You can try Jarod's patch for a day or two and see if it affects your system. When a system is underattack, do you really want to be using a PRNG for anything like How can you be sure that this only happens when a system is under some sort of attack. /dev/urandom is there for user space to use, and we can't make assumptions as to how it will get drawn from. What if someone was running some monte-carlo based test program? That could completely exhaust the entropy in /dev/urandom and would be perfectly legitimate. I doubt a Monte-Carlo simulation will be done in a high security setting where they also depend entirely on a PRNG. seeding openssl? Because a PRNG is what urandom degrades into when its attacked. If enough bytes are read that an attacker can guess the internal state of the RNG, do you really want it seeding a openssh session? At that point you really need it to stop momentarily until it gets fresh entropy so the internal state is unknown. That's what this is really about. I never really want my ssh session to be be seeded with non-random data. Of course, in my mind thats an argument for making ssh use /dev/random rather than /dev/urandom, but I'm willing to take the tradeoff in speed most of the time. Bingo! You hit the problem. In some of our tests, it was shown that it takes 4 minutes to establish a connection when using random. So, if the system is under attack, the seeding of openssh will be based on the output of a RNG where the attacker might be able to guess the internal state. This is a problem we have right now. It not theoretical. The best solution is Jarod's patch because any other solution will require teaching all of user space about the new RNG and dressing it up for FIPS-140. At that point, what's the difference? -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. I thought you need to feed random, not urandom. I think they draw from the same pool. Anyway, it won't happen fast enough to actually not block. Writing 1TB of urandom into a disk won't generate 1TB (or anything close to that) of randomness to cover for itself. We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of 8,000,000:1 or higher. Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparatio n_and_mapping Those instructions might need to be changed. That is one way of many to get random numbers on the disk. Anyone really needing the security to have the sysctl on will also probably accept that its doing its job and keeping the numbers random. Again, no effect unless you turn it on. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 16:56 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. I thought you need to feed random, not urandom. I think they draw from the same pool. There is a blocking and a non blocking pool. Anyway, it won't happen fast enough to actually not block. Writing 1TB of urandom into a disk won't generate 1TB (or anything close to that) of randomness to cover for itself. We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of 8,000,000:1 or higher. I'm just saying that writing 1TB into a disk using urandom will start to block, it won't generate enough randomness by itself. Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparatio n_and_mapping Those instructions might need to be changed. That is one way of many to get random numbers on the disk. Anyone really needing the security to have the sysctl on will also probably accept that its doing its job and keeping the numbers random. Again, no effect unless you turn it on. There are bunch of other places that would need to be changed in that case :) Why not implement it as a user mode CUSE driver that would wrap /dev/urandom and make it behave any way you want to? why push it into the kernel? -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: When a system is underattack, do you really want to be using a PRNG for anything like seeding openssl? Because a PRNG is what urandom degrades into when its attacked. This is not technically true. urandom degrades into a CRNG (cryptographic random number generator). In fact what most security experts recommend is to take a small amount of security, and then use that to seed a CRNG. If enough bytes are read that an attacker can guess the internal state of the RNG, do you really want it seeding a openssh session? In a cryptographic random number generator, there is a either a cryptographic hash or a encryption algorithm at the core. So you would need a huge amounts of bytes, and then you would have to carry out an attack on the cryptographic core. If this is the basis for the patch, then we should definitely NACK it. It sounds like snake oil fear mongering. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On 09/07/2011 10:02 PM, Steve Grubb wrote: When a system is underattack, do you really want to be using a PRNG for anything like seeding openssl? Because a PRNG is what urandom degrades into when its attacked. Using a PRNG is not a problem. Making sure it is well seeded and no input from the attacker can compromise its state are the difficult parts. Making predictable estimates and blocking when your estimates are off, makes it a good target for DoS. When your system is under attack, you want to use your services. If they block then the attack might have just been successful. regards, Nikos -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On 07.09.2011 23:18:58, +0200, Ted Ts'o ty...@mit.edu wrote: Hi Ted, On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: When a system is underattack, do you really want to be using a PRNG for anything like seeding openssl? Because a PRNG is what urandom degrades into when its attacked. This is not technically true. urandom degrades into a CRNG (cryptographic random number generator). In fact what most security experts recommend is to take a small amount of security, and then use that to seed a CRNG. Correct. However, a CRNG shall be reseeded once in a while - see standard crypto libraries and their CRNGs (OpenSSL being a notable exception here). And that is what this entire discussion is all about: to ensure that the CRNG is reseeded with entropy, eventually. If enough bytes are read that an attacker can guess the internal state of the RNG, do you really want it seeding a openssh session? In a cryptographic random number generator, there is a either a cryptographic hash or a encryption algorithm at the core. So you would need a huge amounts of bytes, and then you would have to carry out an attack on the cryptographic core. Correct. And exactly that is the concern from organizations like BSI. Their cryptographer's concern is that due to the volume of data that you can extract from /dev/urandom, you may find cycles or patterns that increase the probability to guess the next random value compared to brute force attack. Note, it is all about probabilities. If this is the basis for the patch, then we should definitely NACK it. It sounds like snake oil fear mongering. - Ted -- Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 05:10:27 PM Sasha Levin wrote: Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Prepar atio n_and_mapping Those instructions might need to be changed. That is one way of many to get random numbers on the disk. Anyone really needing the security to have the sysctl on will also probably accept that its doing its job and keeping the numbers random. Again, no effect unless you turn it on. There are bunch of other places that would need to be changed in that case :) Why not implement it as a user mode CUSE driver that would wrap /dev/urandom and make it behave any way you want to? why push it into the kernel? For one, auditing does not work for FUSE or things like that. We have to be able to audit who is using what. Then there are the FIPS-140 requirements and this will spread it. There are problems sending crypto audit events from user space, too. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
Sasha Levin wrote: On Wed, 2011-09-07 at 16:56 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. I thought you need to feed random, not urandom. I think they draw from the same pool. There is a blocking and a non blocking pool. There's a single shared input pool that both the blocking and non-blocking pools pull from. New entropy data is added to the input pool, then transferred to the interface-specific pools as needed. Anyway, it won't happen fast enough to actually not block. Writing 1TB of urandom into a disk won't generate 1TB (or anything close to that) of randomness to cover for itself. We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of 8,000,000:1 or higher. I'm just saying that writing 1TB into a disk using urandom will start to block, it won't generate enough randomness by itself. Writing 1TB of data to a disk using urandom won't block at all if nobody is using /dev/random. We seed /dev/urandom with entropy, then it just behaves as a Cryptographic RNG, its not pulling out any further entropy data until it needs to reseed, and thus the entropy count isn't dropping to 0, so we're not blocking. Someone has to actually drain the entropy, typically by pulling a fair bit of data from /dev/random, for the blocking to actually come into play. Why not implement it as a user mode CUSE driver that would wrap /dev/urandom and make it behave any way you want to? why push it into the kernel? Hadn't considered CUSE. But it does have the issues Steve mentioned in his earlier reply. Another proposal that has been kicked around: a 3rd random chardev, which implements this functionality, leaving urandom unscathed. Some udev magic or a driver param could move/disable/whatever urandom and put this alternate device in its place. Ultimately, identical behavior, but the true urandom doesn't get altered at all. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, Sep 07, 2011 at 11:27:12PM +0200, Stephan Mueller wrote: And exactly that is the concern from organizations like BSI. Their cryptographer's concern is that due to the volume of data that you can extract from /dev/urandom, you may find cycles or patterns that increase the probability to guess the next random value compared to brute force attack. Note, it is all about probabilities. The internal state of urandom is huge, and it does automatically reseed. If you can find cycles that are significantly smaller than what would be expected by the size of the internal state, (or any kind of pattern at all) then there would be significant flaws in the crypto algorithm used. If the BSI folks think otherwise, then they're peddling snake oil FUD (which is not unusual for security companies). - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 2011-09-07 at 17:28 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 05:10:27 PM Sasha Levin wrote: Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Prepar atio n_and_mapping Those instructions might need to be changed. That is one way of many to get random numbers on the disk. Anyone really needing the security to have the sysctl on will also probably accept that its doing its job and keeping the numbers random. Again, no effect unless you turn it on. There are bunch of other places that would need to be changed in that case :) Why not implement it as a user mode CUSE driver that would wrap /dev/urandom and make it behave any way you want to? why push it into the kernel? For one, auditing does not work for FUSE or things like that. We have to be able to audit who is using what. Then there are the FIPS-140 requirements and this will spread it. There are problems sending crypto audit events from user space, too. auditd doesn't work with FUSE? afaik it should, FUSE is a filesystem like any other. -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wednesday, September 07, 2011 05:35:18 PM Jarod Wilson wrote: Another proposal that has been kicked around: a 3rd random chardev, which implements this functionality, leaving urandom unscathed. Some udev magic or a driver param could move/disable/whatever urandom and put this alternate device in its place. Ultimately, identical behavior, but the true urandom doesn't get altered at all. Right, and that's what I was trying to say is that if we do all that and switch out urandom with something new that does what we need, what's the difference in just patching the behavior into urandom and calling it a day? Its simpler, less fragile, admins won't make mistakes setting up the wrong one in a chroot, already has the FIPS-140 dressing, and is auditable. -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, 7 Sep 2011, Steve Grubb wrote: On Wednesday, September 07, 2011 05:35:18 PM Jarod Wilson wrote: Another proposal that has been kicked around: a 3rd random chardev, which implements this functionality, leaving urandom unscathed. Some udev magic or a driver param could move/disable/whatever urandom and put this alternate device in its place. Ultimately, identical behavior, but the true urandom doesn't get altered at all. Right, and that's what I was trying to say is that if we do all that and switch out urandom with something new that does what we need, what's the difference in just patching the behavior into urandom and calling it a day? Its simpler, less fragile, admins won't make mistakes setting up the wrong one in a chroot, already has the FIPS-140 dressing, and is auditable. I as a 0815 admin would never want such a thing by default. I already replace /dev/random with /dev/urandom to keep stupid sshd from dying because there just is no entropy - I care more about all my services staying alive than about perfect random. c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
On Wed, Sep 07, 2011 at 04:56:49PM -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote: On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote: On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: We're looking for a generic solution here that doesn't require re-educating every single piece of userspace. And anything done in userspace is going to be full of possible holes -- there needs to be something in place that actually *enforces* the policy, and centralized accounting/tracking, lest you wind up with multiple processes racing to grab the entropy. Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. Almost all uses of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those libraries. There are the odd cases where something uses urandom to generate a key or otherwise grab a chunk of bytes, but these are still small reads in the scheme of things. Can you think of any legitimate use of urandom that grabs 100K or 1M from urandom? Even those numbers still won't hit the sysctl on a normally function system. As far as I remember, several wipe utilities are using /dev/urandom to overwrite disks (possibly several times). Which should generate disk activity and feed entropy to urandom. I thought you need to feed random, not urandom. I think they draw from the same pool. They share the primary pool, where timer/interrupt/etc randomness is fed in. /dev/random and /dev/urandom each have their own secondary pools however. Anyway, it won't happen fast enough to actually not block. Writing 1TB of urandom into a disk won't generate 1TB (or anything close to that) of randomness to cover for itself. We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of 8,000,000:1 or higher. Where are you getting that number from? You may not need it, but there are other people using this facility as well that you're not considering. If you assume that in the example Sasha has given, if conservatively, you have a modern disk with 4k sectors, and you fill each 4k sector with the value obtained from a 4 byte read from /dev/urandom, You will: 1) Generate an interrupt for every page you write, which in turn will add at most 12 bits to the entropy pool 2) Extract 32 bits from the entropy pool Thats just a loosing proposition. Barring further entropy generation from another source, this is bound to stall with this feature enabled. Something similar probably happens for getting junk on disks before creating an encrypted filesystem on top of them. During system install, this sysctl is not likely to be applied. It may happen at any time you need to create a new filesystem, which won't necessarily happen during system install. See for example the instructions on how to set up a LUKS filesystem: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparatio n_and_mapping Those instructions might need to be changed. That is one way of many to get random numbers on the disk. Anyone really needing the security to have the sysctl on will also probably accept that its doing its job and keeping the numbers random. Again, no effect unless you turn it on. And then its enforced on everyone, even those applications that don't want it/can't work with it on. This has to be done in such a way that its opt-in on a per-application basis. The CUSE idea put up previously sounds like a pretty good way to do this. The ioctl for per-fd blocking thresholds is another way to go. Neil -Steve -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add blocking facility to urandom
Jarod Wilson ja...@redhat.com wrote: Ted Ts'o wrote: Yeah, but there are userspace programs that depend on urandom not blocking... so your proposed change would break them. ... But only if you've set the sysctl to a non-zero value, ... But again, I want to stress that out of the box, there's absolutely no change to the way urandom behaves, no blocking, this *only* kicks in if you twiddle the sysctl because you have some sort of security requirement that mandates it. So it only breaks things on systems with high security requirements? -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
