Anaconda/Features/EncryptedBlockDevices

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

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:

RAID
These tests mix encryption across raid devices (/dev/md0) and raid members
Encrypted RAID partitions, all mds encrypted	Encrypted RAID partitions, no mds encrypted
Encrypted RAID partitions, some mds encrypted	Select encryption (fs on partition of RAID device (md0))
Select encryption (using RAID block device)	non-encrypted RAID partitions, all mds encrypted
non-encrypted RAID partitions, no mds encrypted	non-encrypted RAID partitions, some mds encrypted
LVM
These tests mix encryption across LVM physical (/dev/sda1) and logical (/dev/mapper/*) volumes
Encrypted LVM VG, all LVs encrypted	Encrypted LVM VG, no LVs encrypted
Encrypted LVM VG, some LVs encrypted	Select encryption (fs on LV of LVM PVs)
Select encryption (using LVM block device)	non-encrypted LVM VG, all LVs encrypted
non-encrypted LVM VG, no LVs encrypted	non-encrypted LVM VG, some LVs encrypted
Partition Probing
Ensure that anaconda will prompt for the passphrase when discovering LUKs encrypted devices during partition probe (rescue mode)
Partition Probing (previous install)
Passphrase Entry
Exercise the different methods of passphrase entry
Enter Passphrase	Enter Passphrase (Create custom layout)
Enter Passphrase (Remove all partitions on selected drives and create default layout)	Enter Passphrase (Resize existing partition and create default layout in free space)
Enter Passphrase (Use free space on selected drives and create default layout)	Enter Passphrase (block device)
Enter Passphrase (non-root filesystem)	Enter Passphrase (root filesystem)
Enter Passphrase to unlock previously encrypted fs
Rescue Mode
Validate that encrypted devices be discovered and managed during rescue-mode operation
rescue mode (non-rootfs is encrypted)	rescue mode (rootfs is encrypted)

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

---