From Fedora Project Wiki
(move to new category naming)
Line 101: Line 101:
Definitely needed
Definitely needed

Revision as of 18:26, 1 August 2008

This page is not being tracked as an Accepted Feature for Fedora 9. The content here should probably be merged with Releases/FeatureEncryptedFilesystems as discussed on #fedora-devel (poelcat 2008-02-07)

Support Creation of Encrypted Block Devices within Anaconda


To support Releases/FeatureEncryptedFilesystems , anaconda needs to grow support for encrypted block devices.


  • Name: DaveLehman

Current status

  • Targeted release: N/A
  • Last updated: 2008-02-05
  • Percentage of completion: 85%
  • Support for creating new devices exists in anaconda
  • Support for automatic partitioning using encrypted devices exists in anaconda
  • Support for creating initrds that can decrypt and mount encrypted devices exists in mkinitrd
  • Support for rescue of systems with encrypted partitions (LUKS only)
  • TODO
  • Discovery and handling (installation/partitioning) of existing encrypted devices in anaconda
  • Improve passphrase prompting dialog (in anaconda) to note which device's passphrase to enter
  • Allow specification of a global passphrase when creating encrypted partitions

Detailed Description

To fully supported encrypted filesystems, we need to be supporting them within the installer. Given that all current momentum is towards the use of LUKS, we need to support LUKS devices within anaconda.

This involves backend code to create LUKS devices, to recognize and unlock existing devices, and UI around the devices.

Benefit to Fedora

Stolen laptops are less likely to have data taken


The main scope of this is within anaconda. There are also pieces that snake out into low-levels of the OS such as mkinitrd and initscripts to ensure that what is being done is consistent across everything.

Test Plan


  • Test that you can create an encrypted block device and boot and use it afterwards
  • Test installation using encrypted block devices only - PartitioningEncryptedAll
  • Test installation using a mix of encrypted/non-encrypted block devices - PartitioningEncryptedMix
  • Test kickstart installation using encrypted block devices - KickstartEncryption
  • Test rescue mode on a system whose root partition is encrypted
  • Test different selinux modes so that it does not prevent this feature from working

2008-04-30 Use case notes from discussion between dlehman and jlaska

RAID Encryption
These tests mix encryption across raid devices (/dev/md0) and raid members
EncryptedRAIDAllMembersEncrypted UnEncryptedRAIDAllMembersEncrypted
EncryptedRAIDSomeMembersEncrypted UnEncryptedRAIDSomeMembersEncrypted
EncryptedRAIDNoMembersEncrypted UnEncryptedRAIDNoMembersEncrypted
LVM Encryption
These tests mix encryption across LVM physical (/dev/sda1) and logical (/dev/mapper/*) volumes
EncryptedLvmPvAllLvsEncrypted UnEncryptedLvmPvAllLvsEncrypted
EncryptedLvmPvSomeLvsEncrypted UnEncryptedLvmPvSomeLvsEncrypted
EncryptedLvmPvNoLvsEncrypted UnEncryptedLvmPvNoLvsEncrypted
Partition Probing
Ensure that anaconda will prompt for the passphrase when discovering LUKs encrypted devices during partition probe (rescue mode)

User Experience

There are a number of pieces of the user experience here. The expert mode is to allow encryption of any individual block device and then to allow unlocking of it at boot.

With our default partitioning setup (/ and swap on LVs of one LVM VG), the best experience is likely to be to have the underlying physical volumes encrypted and with a single passphrase for all volumes.


To fully complete this will require changes to initscripts, mkinitrd and probably some other pieces

Contingency Plan

We disable the code and don't make it visible to the user


  • New --encrypted and --passphrase= options are documented in kickstart.
  • Using /dev/random to fill up the device with junk data is not supported (and will probably not be in future). If you are paranoid you may use the %pre section in kickstart.

Release Notes

Definitely needed