Anaconda/Features/EncryptedBlockDevices

= Support Creation of Encrypted Block Devices within Anaconda =

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

Owner

 * 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

Scope
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
Previously defined cases:
 * 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

Test matrix:

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.

Dependencies
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

Documentation

 * 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