Feature changed by: Arvin Schnell (aschnell) Feature #305633, revision 38 Title: Support installation with encrypted root file system openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Description: One thing openSUSE is really missing, compared with other popular distributions, is the ability to install into an encrypted root file system so _everything_ is encrypted. While the manual installation / setup like described at http://en.opensuse.org/Encrypted_Root_File_System_with_SUSE_HOWTO works, it is still cumbersome and error-prone to setup - especially on systems with small hard disks like e.g. laptops. IMHO this subject gets more and more important not only for laptops but also for normal workstations with respect to the global decline of privacy protection. Since all the necessary software is in place and Yast already has the option (including the GUI) to encrypt /home this shouldn't be that hard to do and would be a great feature for 11.1 (especially if you keep in mind that this will be the base for the next SLE version and corporations love security functionality provided out of the box as an option). Important points are: 1. it should work with LVMs as well 2. it should be possible to automatically generate a key on startup to encrypt the swap partition (given, this would disable suspend) 3. one should be able to use the same password for several partitions so one has to enter it just one time instead of once for every partition. Related reports: * Bug #397411 - Hibernation won't work with encrypted swap * Bug #399298 - encrypt swap partions by default on every boot using a random key * Bug #166067 - sysinfo:/ does not list encrypted /home partition * Bug #467349 - Partitioner does not allow to configure LVM2 on top of DM-Crypt Relations: - Easy to use Full Disk Encryption (feature/id: 304470) - Support installation with encrypted root file system (novell/bugzilla/id: 415479) https://bugzilla.novell.com/show_bug.cgi?id=415479 - Partitioner does not allow to configure LVM2 on top of DM-Crypt (novell/bugzilla/id: 467349) https://bugzilla.novell.com/show_bug.cgi?id=467349 Discussion: #1: Arvin Schnell (aschnell) (2008-08-08 11:39:11) Full disk encryption is already under discussion in fate #304470. Sorry, but it's not public. #2: Stephan Kleine (bitshuffler) (2008-12-17 09:49:10) Reopened because the whole installer was rewritten but still no one cared to add this. I'm sorry, but this feature request is about adding root file system encryption to openSUSE. When, or if at all, you add it to SLE, I couldn't care less about it, but I surely don't want to wait till SLE 12 ;) Also I understand that you don't want to track and update 2 different locations but, since that feature is asked for quite often, IMHO there should be a location for openSUSE users to express their need (as in vote) for it and to CC themself to get notified on updates / when it finally is implemented. Making the fate entry public at https://features.opensuse.org/ would be nice to have as well (since it isn't actual rocket science and suse is one of the last distributions to add this feature there shouldn't be a reason to track this behind closed doors) but I can happily live without it as long as you leave this request open so people can vote for it & cc themself. Thanks a lot. #5: Andreas Jaeger (a_jaeger) (2009-01-21 15:13:20) Bug #467349 says: With the current partitioner in the openSuSE 11.1 Installer it is not possible to configure a partition for encryption using dm-crypt and then using the resulting device for LVM2. This missing feature hurts a lot because it requires the user who wants to encrypt the whole disk including swap to enter multiple passwords at boot. Swap encryption with a user defined password is very useful for encrypted suspend/resume on notebooks. #6: Andreas Jaeger (a_jaeger) (2009-01-21 15:14:14) (reply to #5) If we do this feature, we should check whether we do #5 as well - and then might need to do an extra feature for it. #7: Duncan Mac-Vicar (dmacvicar) (2009-01-30 14:45:44) Duplicate of #304470 ? #8: Olli Artemjev (grey_olli) (2009-05-15 03:42:44) Just my vote - the entire encryption should be supported at installation time.At least I've installed on pc designated to collocation current debian w/entire encription and /boot on removable (usb flash) w/o seriouse problems(short description in Russian here: http://grey-olli.livejournal.com/320477.html) via installation interface - noterminal hand made commands intervention required.I see 3 variants: encrypted devices as physical volumes for LVM volume groups. encryption of LVM logical volumesjust encrypted devices w/o LVMAt least 1st one is easy w/ Debian install now. Hope next SuSE will 've thiseasy too, better if all 3 variants. :) #9: Olli Artemjev (grey_olli) (2009-05-15 03:48:12) generally I guess there're a lot (or some?) of people who're lasy enough to move to anover distribution if it supports secure offline data from the box . At least I've installed Debian due to lacking of entire encryption in SuSE when I had such a must have option. =) #10: Olli Artemjev (grey_olli) (2009-05-15 04:09:31) And one more thing that should be implemented - after suspend to disk & suspend to ram user MUST be prompted for password . A password _must_ be required to decrypt keys used for encrypted storage w/ have suspended too. W/o this anyone smart enough to steal disk & analise it will be able to retrive encrypted data. A password _must_ be required to unlock from suspend to ram or any person awaked laptop will gain encrypted data. /me would be glad if suspending to memory will encrypt in-memory disk encryption keys w/ user password, even if that sounds paranoid. :) Also the screensaver must be uninterruptible - this is musthave - there must be no way to get into w/o entering password. I mean that situation in SLED10 when I'm able to supress gnome screen saver to background is a very bad one. (After suspending screensaver kill screensaver, thus giving touchpad back working & my mounted encrypted data is gained avaliable for anauthorised access, not only my system). Suppressing screensaver in SLED10 was done by fastly click on desctop (or somthing similar, i.e. pressing keys or whatever). Hardware was HP- mini laptop . #11: Olli Artemjev (grey_olli) (2009-05-15 04:18:19) And I've heared about even more secure solution - when user uses external boot w/ key file encrypted by gpg. On boot gpg is decrypting key file. So the user does not know password for encrypted data. If he/she brokes the boot media there's no way to make user reveal the password - it is in autogenerated key file, but after the boot media broken remaining password to decrypt key file is useless. Thus user cannot be forced (by any kind of pressure) to reveal the key to the data - he/she doesn't know it. :-) Implementing this ability in init-rd will give something similar to plausible deniability (though even w/ similar result - forced to reaveal data user doesn't reveal them actually this should be named diffrently I guess - in real plausible deniability there's some false data that is not present in above scenario). #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 10:26:31) Christoph, please reject for openSUSE 11.2 as duplicate of feature 304470 #13: Stephan Kleine (bitshuffler) (2009-06-02 15:19:15) (reply to #12) O rly? That it is a duplicate of #304470 is stated right in the very first comment! The problem just is that you Novell people refuse, for some unknown reason, to track that feature in the public / not behind closed doors. And therefore this feature was created so your beloved "community" also has the possibility to vote / get updated on changes. So please leave either this one alone or make #304470 public! Thanks. #14: Michael Löffler (michl19) (2009-06-02 15:54:38) (reply to #13) Good point. I openened this one again and mark the other one as duplicate. Reason for having the internal one not open is pretty simple: it was created some time prior to the existence of openFATE. #15: Stefan Behlert (sbehlert) (2009-06-02 17:39:39) (reply to #13) And that's the reason why there are still two feature entries. As I mentioned to several people asking me in the last weeks to make one a duplicate of the other _there is information that needs to be consolidated_. (Which to some degree means 'throw away'. Sigh. + #16: Arvin Schnell (aschnell) (2009-06-08 14:51:21) + Adding maintainers of mkinitrd and yast2-bootloader. Those components + must be able to automatically handle a root filesystem and swap (if + possible including suspend to disk) on a logical volume in a volume + group with encrypted physical volumes. -- openSUSE Feature: https://features.opensuse.org/305633