-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2014 08:47 AM, Simo Sorce wrote:
On Mon, 2014-03-03 at 08:00 -0500, Stephen Gallagher wrote:
I'd actually be slightly in favor of leaving encryption support to the custom path, for several reasons:
I am not reasons inline.
- Encrypting a filesystem means that startup/reboot cannot be
handled unattended. Someone will need to provide a password (or insert security device, etc.)
This is true, and should be made clear at install time, but I think we should still encourage people to do encryption by prominently asking if they want it.
- Servers in the "pets" category tend to remain running all the
time. Encryption is only useful when the drive has been removed from the machine.
Which is common, I had raid disk fail in colocation. When they change a disk for me I have no freaking idea what they are going to do with them. The disk is not necessarily completely dead. It may just fail in writing but be perfectly accessible for reading. People should have prayers as the only recourse when a disk fail and some stranger gets in possession of the old disk.
True, I didn't have colocation on my mind when I wrote this. That's an excellent point.
2b) Even if the drive is encrypted only for theft protection, in order to accomplish unattended install, the admin will have to customize the mechanism they use to provide the decryption key, in which case they're likely doing a custom install of the filesystem anyway.
I think we could put encryption keys in the boot partition. Then have a *decommission* command that will wipe the boot. The rest of the disk is encrypted with a lost key at this point and unreadable.
If the /boot is on a totally different disk, you do not even need the wipe step.
An interesting idea, but it doesn't help if you hit the situation above (where writes fail but reads are okay). You wouldn't be able to wipe the key at that point.
Even if the /boot is on a different disk, you have a problem where if that disk is the one that dies, you lose access to all your other data, unless you've got a key escrow system in place.
A magical solution that I could see would be for us to be able to retrieve the key from a network location (such as the FreeIPA Domain Controller?) during system start. We'd have to have network access prior to mounting disks, of course.
And also we'd have to be enrolling in a domain during the installation step, or else we wouldn't be able to escrow the key. Also we'd need to be encrypting the communication, which means that we'd be relying on the keytab (which would have to be available to /boot). This would still be a better situation than having the password on the local system, though. Since at least we could disable the host in FreeIPA as the decommissioning step.
If we could implement all of that, I'd be in favor of making encryption (and this escrow) the default.
Thoughts?
- While much less so than it once was, encryption requires CPU
time to be used on I/O, which is often wasteful in a server environment.
It is often marginal given the CPUs we have today. If you have a heavy I/O bound load then the CPUs are almost always idling wait for data to be written/read from platters anyway. With CPUs having AESNI instructions, this is really not a concern anymore in most cases. (ARM 32 may be an exception to this rule)
Yeah, I'd like to ask the ARM folks if they have numbers on this.
So I'd suggest that Fedora Server recommends the use of LUKS for disk encryption and makes it available in the custom configuration path only.
Thoughts?
See above, I think we should encourage the use of encryption and test it as a common deployment scenario.