Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

To use FDE or not use FDE #511

Closed
runasand opened this issue Jul 31, 2014 · 7 comments

Comments

Projects
None yet
5 participants
@runasand
Copy link
Contributor

commented Jul 31, 2014

According to the ubuntu_config.md guide, we recommend that all deployments use Full Disk Encryption (FDE). Is this the case? I know we have had discussions about the pros and cons of FDE, but I'm not sure if we decided on a yes, no, or we will let the organizations decide for themselves.

@dolanjs

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2014

We originally did recommend FDE but in practice it lead to more issues and believe starting with the .3 release we will not be recomending it anymore. We also had this conversation with @iSEC who agreed that organizations that would enter the facility would be aware of the methods used to extract the private key from running systems, or transfer the device without powering down. That these methods and tools are common to police departments, goverments and other malicious actors.

FDE also was causing servers to be down until an admin was physically present to enter the FDE passphrase after unattended-upgrades reboots for security updates.

FDE added two more unique dice ware passwords that needed to be memorized and manually typed in by the Admin which could lead to insecure passphrase storage that would defeat the point of FDE.

@jlgoz

This comment has been minimized.

Copy link

commented Sep 1, 2014

http://truecrypt.ch hosts the final TC binaries....?

@runasand

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2014

Removed the FDE recommendation from ubuntu_config.md.

@eviljoel

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

Hey, I know this issue is closed, but you might want to consider remote LUKS decryption using Dropbear (http://blog.nguyenvq.com/blog/2011/09/13/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu/). If you could somehow set this up to go over tor, that would be even better. Maybe something to consider for a future version.

@garrettr

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

@eviljoel Thanks, I didn't know that was possible! Looks like it would require some significant changes and testing, but it could be something that would be good to consider for a future release.

@eviljoel

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2014

@garrettr Actually, I potentially found a better option. You can use kexec and a custom, volatile initrd to boot directly into the updated kernel without entering a disk decryption password. I've played around with this in a VM to make sure this is possible. The only problem is some platforms might not work with kexec as some drivers expect hardware to be in a post BIOS, uninitialized state. Should I open another issue for you to research this option?

@eviljoel

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2014

Went ahead and created #816.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.