From Fedora Project Wiki
(Added use case notes from dlehman discussion)
mNo edit summary
Line 1: Line 1:
{{ Template:message/warning | This page is not being tracked as an ''Accepted Feature'' for Fedora 9.  The content here should probably be merged with http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems as discussed on #fedora-devel (poelcat 2008-02-07)  
{{Admon/important | 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 =
= Support Creation of Encrypted Block Devices within Anaconda =


== Summary ==
== Summary ==
Line 25: Line 22:
* Improve passphrase prompting dialog (in anaconda) to note which device's passphrase to enter
* Improve passphrase prompting dialog (in anaconda) to note which device's passphrase to enter
* Allow specification of a global passphrase when creating encrypted partitions
* Allow specification of a global passphrase when creating encrypted partitions


== Detailed Description ==
== Detailed Description ==
Line 45: Line 41:
Cases:
Cases:
* Test that you can create an encrypted block device and boot and use it afterwards
* Test that you can create an encrypted block device and boot and use it afterwards
* Test installation using encrypted block devices only - [http://fedoraproject.org/wiki/QA/TestCases/PartitioningEncryptedAll PartitioningEncryptedAll]  
* Test installation using encrypted block devices only - [[QA/TestCases/PartitioningEncryptedAll |PartitioningEncryptedAll]]  
* Test installation using a mix of encrypted/non-encrypted block devices - [http://fedoraproject.org/wiki/QA/TestCases/PartitioningEncryptedMix PartitioningEncryptedMix]  
* Test installation using a mix of encrypted/non-encrypted block devices - [[QA/TestCases/PartitioningEncryptedMix |PartitioningEncryptedMix]]
* Test kickstart installation using encrypted block devices - [http://fedoraproject.org/wiki/QA/TestCases/KickstartEncryption KickstartEncryption]  
* Test kickstart installation using encrypted block devices - [[QA/TestCases/KickstartEncryption |KickstartEncryption]]
* Test rescue mode on a system whose root partition is encrypted
* 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 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  
2008-04-30 Use case notes from discussion between dlehman and jlaska  
Line 99: Line 94:
== Documentation ==
== Documentation ==


* New --encrypted and --passphrase= options are documented in [http://fedoraproject.org/wiki/Anaconda/Kickstart#head-f35f48e69e34319598484bd4723f79f9ac561cff kickstart] .
* New --encrypted and --passphrase= options are documented in [[Anaconda/Kickstart| 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.
* 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.


Line 106: Line 101:
Definitely needed
Definitely needed


----
[[Category:ProposedFeature]]
[[Category:ProposedFeature]]

Revision as of 20:44, 3 June 2008

Important.png
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

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

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)
EncryptedPartitionProbe

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