-----BEGIN PGP SIGNED MESSAGE-----
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.
> 1) 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.
> 2) 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
> 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
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.
> 3) 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
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
> disk encryption and makes it available in the custom
> configuration path only.
See above, I think we should encourage the use of encryption and
test it as a common deployment scenario.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----