Bug 834463 - Inappropriate use of /dev/urandom
Inappropriate use of /dev/urandom
Status: CLOSED DUPLICATE of bug 807494
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Security_Guide (Show other bugs)
6.5
All Linux
unspecified Severity low
: rc
: ---
Assigned To: Martin Prpič
ecs-bugs
: Documentation
Depends On: 832531
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-21 18:41 EDT by eric@christensenplace.us
Modified: 2012-11-12 07:30 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 832531
Environment:
Last Closed: 2012-11-12 07:30:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description eric@christensenplace.us 2012-06-21 18:41:59 EDT
+++ This bug was initially created as a clone of Bug #832531 +++

Description of problem:

http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html

advises:

Fill your partition with random data: dd if=/dev/urandom of=/dev/VG00/LV_home This process takes many hours to complete.

According to the man page for urandom, the kernel random number generator (/dev/random and /dev/urandom) is intended to supply a small number of bytes of high-quality random data.  It is far too expensive to use for the massive quantities of data needed to initialize disk partitions before encrypted filesystems are created there.

An appropriate use of /dev/urandom would be to obtain a seed value to use as the argument for the C library srand function, then call the rand function for the large amounts of noise needed to initialize a disk.

With disk capacities of multiple terabytes, /dev/urandom could literally take months to generate the necessary amount of data.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

--- Additional comment from ryniker@alum.mit.edu on 2012-06-15 12:39:38 EDT ---

Created attachment 592185 [details]
Small C program to quickly generate large amounts of random data.

--- Additional comment from eric@christensenplace.us on 2012-06-15 12:42:35 EDT ---

(In reply to comment #1)
> Created attachment 592185 [details]
> Small C program to quickly generate large amounts of random data.

It would be better, IMO, to use commands that are already in Fedora than to create a separate program.  I do agree that we should use something other than urandom, though.

--- Additional comment from ryniker@alum.mit.edu on 2012-06-15 13:35:43 EDT ---

(In reply to comment #2)
I agree, but what command?  I thought I could write a suitable program more quickly than I might find one, and wished to illustrate an appropriate use of /dev/urandom.

Perhaps a reader will suggest a good command for this purpose, something like a feature in palimpsest (or some other application already packaged for Fedora) that efficiently performs this function.

The Security Guide should be changed.  That is the purpose of this report.  Until a good idea is developed for what the Security Guide ought to say, my attachment may help users understand and avoid the days or weeks the current instructions may require to complete.

--- Additional comment from eric@christensenplace.us on 2012-06-15 13:57:54 EDT ---

(In reply to comment #3)
> The Security Guide should be changed.  That is the purpose of this report. 
> Until a good idea is developed for what the Security Guide ought to say, my
> attachment may help users understand and avoid the days or weeks the current
> instructions may require to complete.

If you package that program you wrote I'll happily add it to the SG.

--- Additional comment from eric@christensenplace.us on 2012-06-15 15:40:25 EDT ---

I believe we can use 'scrub' to lay down the random bits.  I'm going to do some addtional research on this and see if this is an acceptable replacement.

--- Additional comment from eric@christensenplace.us on 2012-06-15 16:19:59 EDT ---

Created attachment 592223 [details]
Patch removing dd and adding scrub as a solution.

I've created this patch as a recommendation to use scrub instead of dd.

--- Additional comment from eric@christensenplace.us on 2012-06-15 16:32:07 EDT ---

Created attachment 592226 [details]
Patch removing dd and adding scrub as a solution.

Fixed a DocBook XML tag.

--- Additional comment from ryniker@alum.mit.edu on 2012-06-15 17:50:50 EDT ---

"scrub" should do it.  Thank you.

--- Additional comment from eric@christensenplace.us on 2012-06-21 17:27:22 EDT ---

This will be included in the F17 release of the SG.
Comment 1 eric@christensenplace.us 2012-06-21 18:42:48 EDT
Just fixed this in the Fedora Security Guide.  Seems to be a security concern.  Patch is available on the original ticket.
Comment 3 Martin Prpič 2012-11-12 07:30:36 EST
Scrub is not the preferred solution as RHEL ships with scrub version 2.2 which is rather outdated. The fix for this bug uses "shred -v --iterations=1 /dev/VG00/LV_home".

Thanks for reporting!
Martin

*** This bug has been marked as a duplicate of bug 807494 ***

Note You need to log in before you can comment on or make changes to this bug.