Mailinglist Archive: opensuse-features (829 mails)
| < Previous | Next > |
[openFATE 305633] Support installation with encrypted root file system
- From: fate_noreply@xxxxxxx
- Date: Thu, 16 Jul 2009 09:30:20 +0200 (CEST)
- Message-id: <feature-305633-56@xxxxxxxxxxxxxx>
Feature changed by: Jozef Uhliarik (juhliarik)
Feature #305633, revision 56
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.
--
openSUSE Feature:
https://features.opensuse.org/305633
Feature #305633, revision 56
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.
--
openSUSE Feature:
https://features.opensuse.org/305633
| < Previous | Next > |