RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 834463 - Inappropriate use of /dev/urandom
Summary: Inappropriate use of /dev/urandom
Keywords:
Status: CLOSED DUPLICATE of bug 807494
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Security_Guide
Version: 6.5
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Martin Prpič
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On: 832531
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-21 22:41 UTC by eric
Modified: 2012-11-12 12:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 832531
Environment:
Last Closed: 2012-11-12 12:30:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description eric 2012-06-21 22:41:59 UTC
+++ 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.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 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.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 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 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 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 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.edu on 2012-06-15 17:50:50 EDT ---

"scrub" should do it.  Thank you.

--- Additional comment from eric on 2012-06-21 17:27:22 EDT ---

This will be included in the F17 release of the SG.

Comment 1 eric 2012-06-21 22:42:48 UTC
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 12:30:36 UTC
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.