Feature changed by: Andreas Jaeger Feature #305633, revision 2 Title: Support installation with encrypted root file system - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org 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 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 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305633

Feature changed by: Carlo Chiavatore (stakanov) Feature #305633, revision 6 Title: Support installation with encrypted root file system openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) + Interested: Carlo Chiavatore (stakanov) Interested: Richard Weinberger (derrichard) Partner organization: openSUSE.org 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 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 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305633

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305633, revision 15 Title: Support installation with encrypted root file system openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org 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 ? -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Olli Artemjev (grey_olli) Feature #305633, revision 27 Title: Support installation with encrypted root file system openSUSE-11.2: Evaluation 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 . -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Arvin Schnell (aschnell) Feature #305633, revision 29 Title: Support installation with encrypted root file system openSUSE-11.2: Evaluation 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). -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Christoph Thiel (cthiel1) Feature #305633, revision 33 Title: Support installation with encrypted root file system - openSUSE-11.2: Evaluation + openSUSE-11.2: Duplicate of #304470 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 + - feature/duplicate: 304470 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 -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Michael Löffler (michl19) Feature #305633, revision 35 Title: Support installation with encrypted root file system - openSUSE-11.2: Duplicate of #304470 + 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 - - feature/duplicate: 304470 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. -- openSUSE Feature: https://features.opensuse.org/305633

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

Feature changed by: Arvin Schnell (aschnell) Feature #305633, revision 42 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? + #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) + Concerning the proposal: In the meeting we agreed upon adding a + checkbox in the "Suggested Partitioning" dialog but the exact working + was still unclear. "Full Disk Encryption" is technically incorrect. How + should be button be labeled? -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #305633, revision 44 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. + #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) + vote for it! -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #305633, revision 46 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you.   @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? + #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) + Excuse me from the double post. That must have been an error of my + browser not displaying the initial post (openfate does not work at all + with konqueror and obviously just buggy with firefox). + Nonethteless this does not change anything about the basic point of + fact. An OS that does not allow the secure verification of your root fs + against checksums is from a security point of view crap. Without such a + feature there is no way to gain certainity whether your system is + compromised or not. If your system is compromised DO NOT EVEN THINK + about advanced features like ENCRYPTION. It will just be good for + nothing; encryption on a compromised system - how ridiculous!! + Perhaps you have never had the opportunity to experience how it is when + intruders get into tampering your system. There are plenty of tools out + there which do only require minimal changes in order not to be + recognized any more by any chkroot&antivirus software. Actually rpm -Va + is known not to do the job. + From a logically point of view I can only say the following: First + implement a trustable root verification then start to think about + advanced stuff like encryption and signing. The linked feature is of + course not the only way to do this (perhaps I should write about that + too). +   -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Stephan Kleine (bitshuffler) Feature #305633, revision 49 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you.   @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too).   #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). + #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) + Dude, this has absolutely nothing to do with that feature and therefore + I herby politely ask you once again to keep the spam out since that's + not the right place to discuss your problems. + Regarding file system verification: Simply use aide or samhain or + similar stuff like the rest of the world. +   -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Arvin Schnell (aschnell) Feature #305633, revision 51 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? + #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) + I noticed that the dialog "Preparing Hard Disk" also offers the + settings to influence the proposal (separate home, lvm) so the + encryption flag (including password) is also need there. + I think a cleanup of the UI in this area is urgently needed before the + interface gets even more complex. I would like to see reasonable + suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. -   @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). -   #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. -   #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305633, revision 53 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. + #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) + openSUSE is used in different contexts and full disk encryption is + something that has been asked quite a lot as you can also see on the + high number of votes for this feature. Note that you are able to set up + a system the way you want, yast gives you that flexibility. This + feature is to implement the missing parts and that's what Arvin is + going to do. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305633, revision 57 Title: Support installation with encrypted root file system Hackweek IV: Candidate Priority Requester: Desirable Projectmanager: Desirable 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. + #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) + The feature is near to be done. There were described a lot of + scenarious and after diskusion with Arvin the implementation works by + following steps: + * create separate /boot partition (it is not encrypted) + * create encrypted partition for LVM + * create LVM based on encrypted partition + * create logical volumes on LVM (they are not encrypted) + It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ + yast2-bootloader add options "luks_root=partition" to cofiguration file of + bootloader for each boot section with "root" on LVM based on encrypted + partition. + The open issue is support more than only 1 partition for creating LVM + (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The + support of adding "luks_root" and creating initrd config file is done + in yast2-bootloader 2.18.10. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #305633, revision 59 Title: Support installation with encrypted root file system Hackweek IV: Candidate Priority Requester: Desirable Projectmanager: Desirable 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. + #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to + #30) + I am personally in doubt that the votes here reflect real users needs. + They could be due to the lobbying activities of a certain interest + group. Do not trust them blindly. For this time let us complete this + feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Örg Blörg (TheMask) Feature #305633, revision 62 Title: Support installation with encrypted root file system Hackweek IV: Candidate Priority Requester: Desirable Projectmanager: Desirable 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat + #35: Örg Blörg (themask) (2009-07-30 02:19:12) + So what? + IMPLEMENT IT. As for me, full disc encryption (even with pre-boot + authentication) is a MUST. Period. + I really don't understand why everyone is hesitating here. Woudl you be + so friendly and clarify this point for me? Thanks. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305633, revision 64 Title: Support installation with encrypted root file system Hackweek IV: Candidate Priority Requester: Desirable Projectmanager: Desirable 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. + #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) + Leaving out the fact that you could not do basic reading and understand + the status of this feature, I want to remind you, that for the openSUSE + Community product, you are as responsible that a feature gets done as + anyone else, so I would politely ask you from comments like "IMPLEMENT + IT". And no, having an opinion does not count as contribution. Thanks. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Ihno Krumreich (ihno) Feature #305633, revision 72 Title: Support installation with encrypted root file system Hackweek IV: Candidate Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Done 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. + 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Stephan Kleine (bitshuffler) Feature #305633, revision 74 Title: Support installation with encrypted root file system openSUSE-11.2: Done 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. + #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) + The current implementation is suffering from a few problems - e.g. aes- + cbc-essiv is used instead of aes-xts-plain. +   + If you want it more configurable vote for + https://features.opensuse.org/307523 -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305633, revision 79 Title: Support installation with encrypted root file system openSUSE-11.2: Done 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 + #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) + Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 + Ludwig could you add any hints there please? -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Arvin Schnell (aschnell) Feature #305633, revision 81 Title: Support installation with encrypted root file system openSUSE-11.2: Done 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes + #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) + I have backported the changes to yast2-storage for SLE11 SP1. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Ludwig Nussel (lnussel) Feature #305633, revision 83 Title: Support installation with encrypted root file system openSUSE-11.2: Done 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) I have backported the changes to yast2-storage for SLE11 SP1. #45: Jozef Uhliarik (juhliarik) (2009-11-12 14:54:35) If Ludwig backport his fixes to SP1 it is not necessary to do anything in y2-bootloader. Ludwig your comment#43 includes sle11sp2 I hope it is only type and you mean sle11sp1 ;-) Could you confirm it please? + #46: Ludwig Nussel (lnussel) (2009-11-12 15:14:13) (reply to #45) + sle11sp1 of course, yes :-) I think all necessary fixes are in + meanwhile. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Tim - (timsheI) Feature #305633, revision 85 Title: Support installation with encrypted root file system openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) I have backported the changes to yast2-storage for SLE11 SP1. #45: Jozef Uhliarik (juhliarik) (2009-11-12 14:54:35) If Ludwig backport his fixes to SP1 it is not necessary to do anything in y2-bootloader. Ludwig your comment#43 includes sle11sp2 I hope it is only type and you mean sle11sp1 ;-) Could you confirm it please? #46: Ludwig Nussel (lnussel) (2009-11-12 15:14:13) (reply to #45) sle11sp1 of course, yes :-) I think all necessary fixes are in meanwhile. #47: Arvin Schnell (aschnell) (2009-11-17 21:35:53) So everything should be in place. + #48: Tim - (timshei) (2010-05-08 11:49:17) + It seems that there is still a major problem since only the English + keyboard layout is supported on boot which makes entering a strong + password pretty hard. + https://bugzilla.novell.com/show_bug.cgi?id=603744 +   + It would be also great if Yast could support encrypted partitions + without lvm. Not necessarily as an additional option or ready to use + setup configuration but atm it doesn't even allow choosing an encrypted + partition as base for / and similar. Technically it is no problem at + all to create a formatted partition on an encrypted device mapper. + Since there is no (easy?) way to not use Yast for installing OpenSuse + it should be more flexible in this area I think. For example the Ubuntu + Live-CD installer doesn't really support root encryption directly yet + but it is still possible to use it through creating and pre-encrypting + partitions with console tools and selecting this mappers for + installation. +   + Of course without LVM there is the problem of multiple passwords + required if more than one partition is used but this is not a problem + Yast should care about imho and could be circumvented through using key + files. The initrd scripts should just ask for any password needed to + boot. +   + Instead of the already supported key files it would be great if the + Debian script decrypt_derived could be used which generates a key from + an already opened device - root for example - and encrypt/decrypt other + partitions with it which makes it possible to securely open multiple + encrypted partitions with only one safe password. At the same time + there is no need to store the password in an unencrypted file on the + hard disk. But this isn't really a high priority I suppose but not + complicated either since it is already used since quite some time in + Debian. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Miroslav Halas (bastafidli) Feature #305633, revision 90 Title: Support installation with encrypted root file system openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) I have backported the changes to yast2-storage for SLE11 SP1. #45: Jozef Uhliarik (juhliarik) (2009-11-12 14:54:35) If Ludwig backport his fixes to SP1 it is not necessary to do anything in y2-bootloader. Ludwig your comment#43 includes sle11sp2 I hope it is only type and you mean sle11sp1 ;-) Could you confirm it please? #46: Ludwig Nussel (lnussel) (2009-11-12 15:14:13) (reply to #45) sle11sp1 of course, yes :-) I think all necessary fixes are in meanwhile. #47: Arvin Schnell (aschnell) (2009-11-17 21:35:53) So everything should be in place. #48: Tim - (timshei) (2010-05-08 11:49:17) It seems that there is still a major problem since only the English keyboard layout is supported on boot which makes entering a strong password pretty hard. https://bugzilla.novell.com/show_bug.cgi?id=603744   It would be also great if Yast could support encrypted partitions without lvm. Not necessarily as an additional option or ready to use setup configuration but atm it doesn't even allow choosing an encrypted partition as base for / and similar. Technically it is no problem at all to create a formatted partition on an encrypted device mapper. Since there is no (easy?) way to not use Yast for installing OpenSuse it should be more flexible in this area I think. For example the Ubuntu Live-CD installer doesn't really support root encryption directly yet but it is still possible to use it through creating and pre-encrypting partitions with console tools and selecting this mappers for installation.   Of course without LVM there is the problem of multiple passwords required if more than one partition is used but this is not a problem Yast should care about imho and could be circumvented through using key files. The initrd scripts should just ask for any password needed to boot.   Instead of the already supported key files it would be great if the Debian script decrypt_derived could be used which generates a key from an already opened device - root for example - and encrypt/decrypt other partitions with it which makes it possible to securely open multiple encrypted partitions with only one safe password. At the same time there is no need to store the password in an unencrypted file on the hard disk. But this isn't really a high priority I suppose but not complicated either since it is already used since quite some time in Debian. #49: Miroslav Halas (bastafidli) (2011-07-28 21:14:53) This feature is still broken in 11.4 64b. My layout is (no LVM) /boot 100 MB / 20 GB encrypted when I try to create the / I get an error message in installed that / is not supported on encrypted partitions. + #50: Miroslav Halas (bastafidli) (2011-07-29 03:51:01) (reply to #49) + See defect https://bugzilla.novell.com/show_bug.cgi?id=709125 -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Jon Nelson (jnelson-suse) Feature #305633, revision 92 Title: Support installation with encrypted root file system openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) I have backported the changes to yast2-storage for SLE11 SP1. #45: Jozef Uhliarik (juhliarik) (2009-11-12 14:54:35) If Ludwig backport his fixes to SP1 it is not necessary to do anything in y2-bootloader. Ludwig your comment#43 includes sle11sp2 I hope it is only type and you mean sle11sp1 ;-) Could you confirm it please? #46: Ludwig Nussel (lnussel) (2009-11-12 15:14:13) (reply to #45) sle11sp1 of course, yes :-) I think all necessary fixes are in meanwhile. #47: Arvin Schnell (aschnell) (2009-11-17 21:35:53) So everything should be in place. #48: Tim - (timshei) (2010-05-08 11:49:17) It seems that there is still a major problem since only the English keyboard layout is supported on boot which makes entering a strong password pretty hard. https://bugzilla.novell.com/show_bug.cgi?id=603744 It would be also great if Yast could support encrypted partitions without lvm. Not necessarily as an additional option or ready to use setup configuration but atm it doesn't even allow choosing an encrypted partition as base for / and similar. Technically it is no problem at all to create a formatted partition on an encrypted device mapper. Since there is no (easy?) way to not use Yast for installing OpenSuse it should be more flexible in this area I think. For example the Ubuntu Live-CD installer doesn't really support root encryption directly yet but it is still possible to use it through creating and pre-encrypting partitions with console tools and selecting this mappers for installation. Of course without LVM there is the problem of multiple passwords required if more than one partition is used but this is not a problem Yast should care about imho and could be circumvented through using key files. The initrd scripts should just ask for any password needed to boot. Instead of the already supported key files it would be great if the Debian script decrypt_derived could be used which generates a key from an already opened device - root for example - and encrypt/decrypt other partitions with it which makes it possible to securely open multiple encrypted partitions with only one safe password. At the same time there is no need to store the password in an unencrypted file on the hard disk. But this isn't really a high priority I suppose but not complicated either since it is already used since quite some time in Debian. #49: Miroslav Halas (bastafidli) (2011-07-28 21:14:53) This feature is still broken in 11.4 64b. My layout is (no LVM) /boot 100 MB / 20 GB encrypted when I try to create the / I get an error message in installed that / is not supported on encrypted partitions. #50: Miroslav Halas (bastafidli) (2011-07-29 03:51:01) (reply to #49) See defect https://bugzilla.novell.com/show_bug.cgi?id=709125 + #51: Jon Nelson (jnelson-suse) (2013-01-24 16:35:46) + What's the current status here? We're at almost openSUSE 12.3 and *four + years* after this FATE issue was created. I did a *painless* full-disk- + encryption install using Fedora 17 just a few days ago, and Ubuntu + supports this type of thing, too. We should be able to do FDE without + using LVM trivially. I've always had to do the FDE post-install, but it + works just fine. -- openSUSE Feature: https://features.opensuse.org/305633

Feature changed by: Carlos Robinson (robin_listas) Feature #305633, revision 95 Title: Support installation with encrypted root file system openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org 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. #17: Arvin Schnell (aschnell) (2009-06-16 16:35:49) So far for some reason encryption is disabled on S390. Should encryption be generally allowed (single volume and physical volumes) on S390 now? #18: Arvin Schnell (aschnell) (2009-07-07 11:27:57) Concerning the proposal: In the meeting we agreed upon adding a checkbox in the "Suggested Partitioning" dialog but the exact working was still unclear. "Full Disk Encryption" is technically incorrect. How should be button be labeled? #28: Arvin Schnell (aschnell) (2009-07-08 16:46:50) (reply to #18) I noticed that the dialog "Preparing Hard Disk" also offers the settings to influence the proposal (separate home, lvm) so the encryption flag (including password) is also need there. I think a cleanup of the UI in this area is urgently needed before the interface gets even more complex. I would like to see reasonable suggestions. #19: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:02) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! (see: Feature 306508, https://features.opensuse.org/306508; vote for it!). Otherwise things like signing and encryption can be circumvented and definitely do not make sense. #20: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:40:43) https://features.opensuse.org/306508 #21: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:43:14) Before we think about advanced features like encryption we must find a way to make sure that our system has not been compromised! see Feature 306508, https://features.opensuse.org/306508. Otherwise things like signing and encryption definitely do not make sense because they can be circumvented easily. #22: Elmar Stellnberger ATK (estellnb) (2009-07-07 11:44:19) vote for it! #23: Stephan Kleine (bitshuffler) (2009-07-07 13:39:17) (reply to #22) Please refrain from spamming other features to advertise your pet peeve and keep such to forums or mailing lists since it doesn't add anything of value here (even more if you do it 3 times). Thank you. @Arvin: "Encrypted Filesystem" & some note that /boot is left unencrypted? #24: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:16:20) Excuse me from the double post. That must have been an error of my browser not displaying the initial post (openfate does not work at all with konqueror and obviously just buggy with firefox). Nonethteless this does not change anything about the basic point of fact. An OS that does not allow the secure verification of your root fs against checksums is from a security point of view crap. Without such a feature there is no way to gain certainity whether your system is compromised or not. If your system is compromised DO NOT EVEN THINK about advanced features like ENCRYPTION. It will just be good for nothing; encryption on a compromised system - how ridiculous!! Perhaps you have never had the opportunity to experience how it is when intruders get into tampering your system. There are plenty of tools out there which do only require minimal changes in order not to be recognized any more by any chkroot&antivirus software. Actually rpm -Va is known not to do the job. From a logically point of view I can only say the following: First implement a trustable root verification then start to think about advanced stuff like encryption and signing. The linked feature is of course not the only way to do this (perhaps I should write about that too). #25: Elmar Stellnberger ATK (estellnb) (2009-07-07 17:37:34) To my mind there are simply plenty of other security issues of much higher importance. What about about Apparmor? It is still not available for kernel 2.6.30! ... but would be highly required since there is no way to work seriously with Opensuse and kernel 2.6.27 (https://bugzilla.novell.com/show_bug.cgi?id=465039). Besides this opensuse.org/security could do with some amelioration. Encrypt your root fs by one click via Yast! That sounds good but will actually be good for nothing. Those who really need it should read on how to do it manually (alter your initrd etc.). #26: Stephan Kleine (bitshuffler) (2009-07-07 19:22:55) (reply to #25) Dude, this has absolutely nothing to do with that feature and therefore I herby politely ask you once again to keep the spam out since that's not the right place to discuss your problems. Regarding file system verification: Simply use aide or samhain or similar stuff like the rest of the world. #27: Elmar Stellnberger ATK (estellnb) (2009-07-08 11:46:09) The feature sounds cool and progressive. Besides this I can hardly imagine any desktop user to burden himself with a complete system encryption. A complete system encryption will make sense to a CI- officer or perhaps to a boss hiding accounts and other documents of interest from the finance or from competitors. Isn`t it enough to encrypt the home partition and perhaps the swap/resume device? I guess most desktop users will avoid encryption at all because performance is simply of higher importance. #30: Andreas Jaeger (a_jaeger) (2009-07-09 15:05:46) (reply to #27) openSUSE is used in different contexts and full disk encryption is something that has been asked quite a lot as you can also see on the high number of votes for this feature. Note that you are able to set up a system the way you want, yast gives you that flexibility. This feature is to implement the missing parts and that's what Arvin is going to do. #33: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:55:58) (reply to #30) I am personally in doubt that the votes here reflect real users needs. They could be due to the lobbying activities of a certain interest group. Do not trust them blindly. For this time let us complete this feature since it is almost ready. #29: Elmar Stellnberger ATK (estellnb) (2009-07-09 10:46:49) o.k. we additionally need to encrypt /var & /tmp & /srv but we usually should not need to encrypt /usr, /etc, /lib[64], /[s]bin, /boot. It should improve performance if the /usr-programs are not encrypted. #31: Jozef Uhliarik (juhliarik) (2009-07-24 16:34:09) The feature is near to be done. There were described a lot of scenarious and after diskusion with Arvin the implementation works by following steps: * create separate /boot partition (it is not encrypted) * create encrypted partition for LVM * create LVM based on encrypted partition * create logical volumes on LVM (they are not encrypted) It is describe at http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/ yast2-bootloader add options "luks_root=partition" to cofiguration file of bootloader for each boot section with "root" on LVM based on encrypted partition. The open issue is support more than only 1 partition for creating LVM (work for mkinitrd) otherwise the feature is done for openSUSE 11.2 The support of adding "luks_root" and creating initrd config file is done in yast2-bootloader 2.18.10. #32: Stephan Kleine (bitshuffler) (2009-07-24 19:07:51) (reply to #31) I'm sorry if I sound like an ungrateful bugger but do I get you right that for using an encrypted root using LVM is mandatory then? If so it sucks pretty hard IMHO since it imposes an unnecessary restriction on the user. Also other distros make it possible without enforcing LVM usage. Therefore please make it possible without LVM as well. #34: Jiri Srain (jsrain) (2009-07-27 14:28:23) (reply to #32) Stephan, you got it right, LVM is necessary for using encrypted root with YaST installer. While for you it is a restriction, others would complain if a combination with LVM was not possible. We are not able to support all scenarios needed to make everybody happy. LVM brings more flexibility than plain partitioning and whole physical volume is unencrypted via a single password (think of separate /usr or /home). This approach is also used by other distros, e.g. Red Hat #35: Örg Blörg (themask) (2009-07-30 02:19:12) So what? IMPLEMENT IT. As for me, full disc encryption (even with pre-boot authentication) is a MUST. Period. I really don't understand why everyone is hesitating here. Woudl you be so friendly and clarify this point for me? Thanks. #36: Stephan Kleine (bitshuffler) (2009-07-30 06:04:13) (reply to #35) You apparently either failed to get the obvious or at basic reading ... They said it is implemented and it is working. My comment was targeted at the need to use LVM instead of being able to use it without LVM but simply per disk / partition - even if that would result in no support for sleep / hibernate. So, to try to say it in a language you probably understand: First learn to read, then try to understand what you read, then get a clue and after that try to express your opinion in some polite manner. Regarding the "even with pre-boot authentication": please get a clue first and until then refrain from spamming here with impolite crap that leads nowhere. kthxbye. I hope that was put down in a way you can understand. #37: Duncan Mac-Vicar (dmacvicar) (2009-08-03 11:45:45) (reply to #35) Leaving out the fact that you could not do basic reading and understand the status of this feature, I want to remind you, that for the openSUSE Community product, you are as responsible that a feature gets done as anyone else, so I would politely ask you from comments like "IMPLEMENT IT". And no, having an opinion does not count as contribution. Thanks. #38: Arvin Schnell (aschnell) (2009-08-17 11:36:25) Marking as done for openSUSE 11.2 although there are some bugs left. #40: Stephan Kleine (bitshuffler) (2009-08-27 21:39:05) The current implementation is suffering from a few problems - e.g. aes- cbc-essiv is used instead of aes-xts-plain. If you want it more configurable vote for https://features.opensuse.org/307523 #42: Jozef Uhliarik (juhliarik) (2009-10-13 15:13:11) Maybe helps if Ludwig Nussel also add his fix for SP1. see bnc#528474 Ludwig could you add any hints there please? #43: Ludwig Nussel (lnussel) (2009-10-13 16:01:13) (reply to #42) I'll have to backport the fixes from 11.2 to sle11sp2, yes #44: Arvin Schnell (aschnell) (2009-10-14 17:28:19) I have backported the changes to yast2-storage for SLE11 SP1. #45: Jozef Uhliarik (juhliarik) (2009-11-12 14:54:35) If Ludwig backport his fixes to SP1 it is not necessary to do anything in y2-bootloader. Ludwig your comment#43 includes sle11sp2 I hope it is only type and you mean sle11sp1 ;-) Could you confirm it please? #46: Ludwig Nussel (lnussel) (2009-11-12 15:14:13) (reply to #45) sle11sp1 of course, yes :-) I think all necessary fixes are in meanwhile. #47: Arvin Schnell (aschnell) (2009-11-17 21:35:53) So everything should be in place. #48: Tim - (timshei) (2010-05-08 11:49:17) It seems that there is still a major problem since only the English keyboard layout is supported on boot which makes entering a strong password pretty hard. https://bugzilla.novell.com/show_bug.cgi?id=603744 It would be also great if Yast could support encrypted partitions without lvm. Not necessarily as an additional option or ready to use setup configuration but atm it doesn't even allow choosing an encrypted partition as base for / and similar. Technically it is no problem at all to create a formatted partition on an encrypted device mapper. Since there is no (easy?) way to not use Yast for installing OpenSuse it should be more flexible in this area I think. For example the Ubuntu Live-CD installer doesn't really support root encryption directly yet but it is still possible to use it through creating and pre-encrypting partitions with console tools and selecting this mappers for installation. Of course without LVM there is the problem of multiple passwords required if more than one partition is used but this is not a problem Yast should care about imho and could be circumvented through using key files. The initrd scripts should just ask for any password needed to boot. Instead of the already supported key files it would be great if the Debian script decrypt_derived could be used which generates a key from an already opened device - root for example - and encrypt/decrypt other partitions with it which makes it possible to securely open multiple encrypted partitions with only one safe password. At the same time there is no need to store the password in an unencrypted file on the hard disk. But this isn't really a high priority I suppose but not complicated either since it is already used since quite some time in Debian. #49: Miroslav Halas (bastafidli) (2011-07-28 21:14:53) This feature is still broken in 11.4 64b. My layout is (no LVM) /boot 100 MB / 20 GB encrypted when I try to create the / I get an error message in installed that / is not supported on encrypted partitions. #50: Miroslav Halas (bastafidli) (2011-07-29 03:51:01) (reply to #49) See defect https://bugzilla.novell.com/show_bug.cgi?id=709125 #51: Jon Nelson (jnelson-suse) (2013-01-24 16:35:46) What's the current status here? We're at almost openSUSE 12.3 and *four years* after this FATE issue was created. I did a *painless* full-disk- encryption install using Fedora 17 just a few days ago, and Ubuntu supports this type of thing, too. We should be able to do FDE without using LVM trivially. I've always had to do the FDE post-install, but it works just fine. #52: Stefan Behlert (sbehlert) (2013-01-28 12:20:22) (reply to #51) It's marked as done - so if somethings not working - bugzilla. For improvements - new faeture entry. + #53: Carlos Robinson (robin_listas) (2013-08-10 14:20:44) (reply to + #51) + The status is that the feature is implemented - with encrypted LVM. If you + want encryption on a normal, non LVM, root partition, that's a + different feature and you have to request it on a new openFATE entry. + If you do, please post the number here so that we can vote it. -- openSUSE Feature: https://features.opensuse.org/305633