[opensuse-security] re-attaching luks encrypted partition without need of re-entering passphrase
Hi folks, I need an idea how to solve a problem concerning automated opening and closing of encrypted partitions. Maybe one of you can help me. On an openSUSE 11.3 laptop, I set up all hard disk partitions (in the easiest case just root and swap) as encrypted partitions using luks as described in http://en.opensuse.org/SBD:Encrypted_root_file_system This works quite well. As boot partition I use a memstick, and this works aswell. Then I thought I'd like to use suspend to disk mechanism. First question: How well encrypted is the written-out RAM in such a setting? In case it is as well encrypted as the rest of the harddisk, all is fine and there's no need to solve the rest of the problem. In case the encryption of the written-out RAM is weaker, let me continue. As long as I use the harddisk's swap as resume partition, this works well. Now my boss had the idea to use a swap partition on the memstick as suspend/resume partition instead. I got that up without fuss for the case that the memstick is inserted at boot time and not removed. As the swap on memstick is quite slow, I only add it to the system's swap for suspend to disk. Took me writing a little script for the suspend-to-disk acpi event, but that's up and running too. But my boss wants to insert the memstick at boot time, then remove it as soon as booting is done. Then he wants to insert it again for supend to disk. In principle that's fine with me. The problem with this is that - I have to remove the resume partition (the swap on the memstick) from the device mapper after boot. Not solved yet, but I think this should be easily solved with an appropriate 'start' script. - I need to re-attach this partition, the memstick's swap partition, before suspend to disk is executed. And for this, I need that partition's passphrase! Unfortunately the suspend-to-disk acpi event script does not run interactively, so it cannot directly prompt for passphrase. I personally could live with only calling suspend-to-disk from command line, which would offer the possibility to prompt for the passphrase. I am setting this up for my collegues though, who are already used to using the laptop's function key. So I need a way to re-attach the resume partition on the memstick *without* any user-interaction for the passphrase. The only solution I could find up to now (though not tested yet) would be to hard-code this passphrase in the script, but I would like to avoid that. So here's my question: As luks already prompted for the passphrase during boot, is there a way to access this passphrase during this re-mount of the memstick's swap partition? Any way of keeping this partition's information although the memstick is removed (and re-attached) in the time between boot and suspend-to-disk? Thanks for any ideas, Susan -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Susan Dittmar wrote:
On an openSUSE 11.3 laptop, I set up all hard disk partitions (in the easiest case just root and swap) as encrypted partitions using luks as described in http://en.opensuse.org/SBD:Encrypted_root_file_system
Uh, that article should probably be removed. The preferred method to have an encrypted root is to just click the checkbox in yast during installation.
But my boss wants to insert the memstick at boot time, then remove it as soon as booting is done. Then he wants to insert it again for supend to disk. In principle that's fine with me. The problem with this is that
Sounds cumbersome and error prone. What's wrong with suspending to the built in hard disk?
So here's my question: As luks already prompted for the passphrase during boot, is there a way to access this passphrase during this re-mount of the memstick's swap partition? Any way of keeping this partition's information although the memstick is removed (and re-attached) in the time between boot and suspend-to-disk?
The passphrase is gone when cryptsetup finishes. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Ludwig Nussel wrote:
Susan Dittmar wrote:
On an openSUSE 11.3 laptop, I set up all hard disk partitions (in the easiest case just root and swap) as encrypted partitions using luks as described in http://en.opensuse.org/SBD:Encrypted_root_file_system
Uh, that article should probably be removed. The preferred method to have an encrypted root is to just click the checkbox in yast during installation.
But my boss wants to insert the memstick at boot time, then remove it as soon as booting is done. Then he wants to insert it again for supend to disk. In principle that's fine with me. The problem with this is that
Sounds cumbersome and error prone. What's wrong with suspending to the built in hard disk?
What if the swap is not encrypted? If you want to go for minimum (or no) user input, you have to use some physical token (for resuming). In some aspects this resembles the traditional corporate practice of using smartcard enabled workstations. What about triggering the suspend process by media insert event (with the correct uuid). The script would search for specific data on the media - a key that would be used for encrypting the hibernation image to hard drive using the key from the memory stick. Upon boot from the memory stick, the key would be used to decrypt the image. Additionally, you could use asymmetric encryption*): encrypting the hibernation image with public key (no password needed). Decrypting could then require a password - depending on whether the private key is itself encrypted on the boot media. *) in the traditional way: generate random symmetric cipher key and encrypt with asymmetric algo.
So here's my question: As luks already prompted for the passphrase during boot, is there a way to access this passphrase during this re-mount of the memstick's swap partition? Any way of keeping this partition's information although the memstick is removed (and re-attached) in the time between boot and suspend-to-disk?
If you encrypt the hibernation image, you can safely keep all stuff (local - i.e. not usb etc. that might be removed prior to resume) mounted so no need to remount upon resume.
The passphrase is gone when cryptsetup finishes.
Theoretically it could be kept in /proc/keys, right? Cheers Petr -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 14:20 +0200, Petr Cerny wrote:
Ludwig Nussel wrote:
Uh, that article should probably be removed. The preferred method to have an encrypted root is to just click the checkbox in yast during installation.
What if the swap is not encrypted? If you want to go for minimum (or no) user input, you have to use some physical token (for resuming).
I understand that the current trick to encript both root and swap in openSUSE is to use an encripted LVM, and inside put both root and swap. Thus the password is only entered once, when resuming. And of course, the encription for memory in swap is as good as for root, it is phisically the same. I don't like this method because I don't like LVM much.
In some aspects this resembles the traditional corporate practice of using smartcard enabled workstations.
I read somewhere about using encripted filesystems that needed both a typed passphrase and a removable "something" with a big key. But I have no idea how to create and use such a thing.
The passphrase is gone when cryptsetup finishes.
Theoretically it could be kept in /proc/keys, right?
No use when resuming: it will be inside swap which you can not recover till the process knows the password. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky0+CQACgkQtTMYHG2NR9XWigCeOdUT9CwfLvim6cZOvmI3Z0Dl kRkAoIzkurm6/+d10gs/iDBgHcKn5pal =dfBr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Dear Carlos, thanks for your answer. Quoting Carlos E. R. (robin.listas@telefonica.net):
I understand that the current trick to encript both root and swap in openSUSE is to use an encripted LVM, and inside put both root and swap. Thus the password is only entered once, when resuming. And of course, the encription for memory in swap is as good as for root, it is phisically the same.
I don't like this method because I don't like LVM much.
Hm. I share your feelings towards LVM. But maybe I will try that nonetheless. I do not like LUKS either, because encrypting a partition and then writing in plain text most of the information how to decrypt it sounds like locking the door and then leaving information about how to obtain the key under the doormat. Nonetheless I already decided to use LUKS, mainly because I did not manage to make things run without.
The passphrase is gone when cryptsetup finishes.
Theoretically it could be kept in /proc/keys, right?
No use when resuming: it will be inside swap which you can not recover till the process knows the password.
Ah, you misunderstood. There's no problem with typing the passphrase for resuming. Problem is the suspend part -- here I would prefer to just have to press *one* key (the laptop's prebuilt function key) for the laptop to shut down. For this suspend to disk in my current setup I need to re-attach the needed swap space to the system, and this re-attachment needs the key. Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Wed, 13 Oct 2010 10:40:57 +0200 Susan Dittmar <SDittmar@eureca.de> wrote:
Ah, you misunderstood. There's no problem with typing the passphrase for resuming. Problem is the suspend part -- here I would prefer to just have to press *one* key (the laptop's prebuilt function key) for the laptop to shut down.
Encrypted suspend is part of uswsusp. Please read /usr/share/doc/packages/suspend/README.encryption, set "encrypt = y" (and "threads = y" if you have a multi-core CPU) in /etc/suspend.conf, then run /usr/sbin/suspend-keygen I did not try this for quite some time, but it worked well once upon a time. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 10:48 +0200, Stefan Seyfried wrote:
On Wed, 13 Oct 2010 10:40:57 +0200 Susan Dittmar <> wrote:
Ah, you misunderstood. There's no problem with typing the passphrase for resuming. Problem is the suspend part -- here I would prefer to just have to press *one* key (the laptop's prebuilt function key) for the laptop to shut down.
Encrypted suspend is part of uswsusp.
Please read /usr/share/doc/packages/suspend/README.encryption, set "encrypt = y" (and "threads = y" if you have a multi-core CPU) in /etc/suspend.conf, then run /usr/sbin/suspend-keygen
I did not try this for quite some time, but it worked well once upon a time.
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else. Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ⁽¹⁾. On restore from hibernation, it would ask for the password only once: for the swap. The partitions are mounted, no password required. I wonder what would happen on a failed wake up, would the fsck script ask for the password, or would it fail? - - (1) I think that asking for the password several times can not be helped while booting, or developers or openSUSE maintainers would have used such a method for yast, instead of using the LVM kludge. If a method existed they would have used it. I hope! - - Another possibility would be hardware encryption, directly by the HD firmware. Search for "ATA Security Feature Set" in man hdparm. I have never used this in Linux - I know of people that used it in windows. I don't know who has to ask for the password, I think the bios: not even the MBR can be read if the lock is set. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky1t/wACgkQtTMYHG2NR9WEjQCgjybBdB1PCPbm+sgwnyJLnrlC s8EAoIaZANQsEW9ZjnV4ycjLTr/C1QB2 =JLqX -----END PGP SIGNATURE-----
Dear Carlos, Quoting Carlos E. R. (robin.listas@telefonica.net):
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else.
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ?¹?.
When following the aforementioned SDB article in creating several encrypted partitions (all with luks), the system only asks for one passphrase during boot in case all passphrases are the same. To be more precise, it asks for first passphrase, unlocks first partition, then for the next partition it first tries with the first passphrase and only asks for a new one if the first one does not do the job. I did't test with a scenario where the first and second passphrase differ, and the third is equal to the first, so I do not know if for a third partition both first and second would be checked before prompting for third passphrase.
On restore from hibernation, it would ask for the password only once: for the swap. The partitions are mounted, no password required.
It's the other way 'round here too, at least in my setting: It *does* ask for *all* passphrases on restore from hibernation too. Maybe that's due to the fact that the information about which partitions to unlock is given as kernel boot parameters. I might try a more YaST-guided setup next, where all partitions safe root (which cannot be done) are encrypted already by YaST. Maybe I will find a better combination of kernel boot parameters and initrd-scripts when using that. (Better in the sense that on wakeup only the resume partition's passphrase will be needed.) That might take a day or two though.
I wonder what would happen on a failed wake up, would the fsck script ask for the password, or would it fail?
I don't think so. If I understand correctly, fsck checks the partitions given by root and by /etc/fstab. The root given to fsck is the next layer above the device mapper, which means the already-unlocked partition. If unlocking fails, fsck cannot even find the device it should check.
Another possibility would be hardware encryption, directly by the HD firmware. Search for "ATA Security Feature Set" in man hdparm. I have never used this in Linux - I know of people that used it in windows. I don't know who has to ask for the password, I think the bios: not even the MBR can be read if the lock is set.
I will look into that. Thanks! Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 17:19 +0200, Susan Dittmar wrote:
Dear Carlos,
Quoting Carlos E. R. (robin.listas@telefonica.net):
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else.
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ?¹?.
When following the aforementioned SDB article in creating several encrypted partitions (all with luks), the system only asks for one passphrase during boot in case all passphrases are the same.
Ah, I see.
On restore from hibernation, it would ask for the password only once: for the swap. The partitions are mounted, no password required.
It's the other way 'round here too, at least in my setting: It *does* ask for *all* passphrases on restore from hibernation too. Maybe that's due to the fact that the information about which partitions to unlock is given as kernel boot parameters.
Ah! No, I think I know why: you don't have a separate unencripted /boot partition - is that it?
Another possibility would be hardware encryption, directly by the HD firmware. Search for "ATA Security Feature Set" in man hdparm. I have never used this in Linux - I know of people that used it in windows. I don't know who has to ask for the password, I think the bios: not even the MBR can be read if the lock is set.
I will look into that. Thanks!
Tell us what you find, I'm curious about that system. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky12PcACgkQtTMYHG2NR9XNJgCgjFDki2qAvjMQZsdrPxWUJcSc zGkAn2zq7CPw2u5/hEtwy6FeixQdRT8E =aLgU -----END PGP SIGNATURE-----
Dear Carlos, Quoting Carlos E. R. (robin.listas@telefonica.net):
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ?¹?.
Last night I tested another setup using YaST to set up the encrypted partitions. Now I understand why you wrote I would have to type the password for every partition -- with YaST's setup, I have to. I did just two reboots, and already I hate myself for having chosen a long passphrase. On the other hand, I *want* a long passphrase! So it's either provide for an additional key as proposed by Christian Boltz or find out how to activate the 'try reusing key before asking for a new one' I had before for the YaST-generated setup. Christian Boltz' idea would also solve my main problem: automatically re-mounting the encrypted suspend-to-disk swap partition during suspend. On the other hand it would mean having passwords on the root partition, which I would like to avoid. Stefan, I will read more about uswsusp too. I'm sure I can learn interesting things from that too, and maybe I'll use it. Thanks again for the input, Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Citeren Susan Dittmar <SDittmar@eureca.de>:
Christian Boltz' idea would also solve my main problem: automatically re-mounting the encrypted suspend-to-disk swap partition during suspend. On the other hand it would mean having passwords on the root partition, which I would like to avoid.
Why? If someone manages to guess the password to decrypt your root partition *and* also gains root access, you're toast anyway. They will effectively own the system and will be able to install whatever is needed to record the passwords that are entered for mounting the other partitions. Best regards, Arjen -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Wed, 13 Oct 2010 15:45:31 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else.
Please read what I wrote. Thank you. I wrote nothing about encrypted swap. No need to enter a passphrase during boot and resume. Only during resume. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 17:32 +0200, Stefan Seyfried wrote:
On Wed, 13 Oct 2010 15:45:31 +0200 (CEST) "Carlos E. R." <> wrote:
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else.
Please read what I wrote. Thank you. I wrote nothing about encrypted swap. No need to enter a passphrase during boot and resume. Only during resume.
Yes, you did:
Encrypted suspend is part of uswsusp.
Suspend data is sent to swap, thus swap has to be encripted. If what you mean, but did not explain, is that the entire swap is not encripted, but just the suspend image is,... that's a different thing, and not safe, IMO. Not safe because then anything the kernel sends to swap before the suspend image would not be encripted, meaning some programs parts and data. That is dangerous. Otherwise, please explain. And how do you combine that partial encription with the fact that at least the home partition, and perhaps all partitions, are LUK encripted? The user would have to type several times the password. Once for the partitions, another for the suspend image... - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky12xAACgkQtTMYHG2NR9Ut9QCfa0ycF2y+y4wnNFEAJS7Z8TQ4 VGUAnR0VggwoewgP39KAU0rz2DF9cQCA =LDzP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Wed, 13 Oct 2010 18:15:11 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
Please read what I wrote. Thank you. I wrote nothing about encrypted swap. No need to enter a passphrase during boot and resume. Only during resume.
Yes, you did:
Encrypted suspend is part of uswsusp.
Suspend data is sent to swap, thus swap has to be encripted.
I'd use a separate unencrypted swap partition for that.
If what you mean, but did not explain, is that the entire swap is not encripted, but just the suspend image is,... that's a different thing, and not safe, IMO.
See above. Separate unencrypted swap partition for hibernate.
And how do you combine that partial encription with the fact that at least the home partition, and perhaps all partitions, are LUK encripted? The user would have to type several times the password. Once for the partitions, another for the suspend image...
They are not unmounted during suspend, so do not need to be remounted and thus no passphrase needs to be entered. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 18:22 +0200, Stefan Seyfried wrote:
On Wed, 13 Oct 2010 18:15:11 +0200 (CEST) "Carlos E. R." <t> wrote:
See above. Separate unencrypted swap partition for hibernate.
How would you configure those two? Meaning what to do on fstab, what on kernel boot line, in order to do that. I have no idea how to separate both things. If you have a link that explain that method, please post it.
And how do you combine that partial encription with the fact that at least the home partition, and perhaps all partitions, are LUK encripted? The user would have to type several times the password. Once for the partitions, another for the suspend image...
They are not unmounted during suspend, so do not need to be remounted and thus no passphrase needs to be entered.
Only if /boot is separate and not encripted, or no way to read the kernel. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky14X0ACgkQtTMYHG2NR9WbtACaAsPlT6uvseLyL/GEp4/Ro8BP xSsAn0xIVlVb4jUg3p7H+ZE+uM+9CtDJ =s17f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Stefan Seyfried wrote:
On Wed, 13 Oct 2010 18:15:11 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
Please read what I wrote. Thank you. I wrote nothing about encrypted swap. No need to enter a passphrase during boot and resume. Only during resume.
Yes, you did:
Encrypted suspend is part of uswsusp.
Suspend data is sent to swap, thus swap has to be encripted.
I'd use a separate unencrypted swap partition for that.
Then you can go without any encryption at all (almost). Uneencrypted hibernation image would contain all the data you'd need for accessing any encrypted partitions mounted at the time of hibernating. Petr -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Thu, 14 Oct 2010 19:45:00 +0200 Petr Cerny <pcerny@suse.cz> wrote:
Stefan Seyfried wrote:
I'd use a separate unencrypted swap partition for that.
Then you can go without any encryption at all (almost). Uneencrypted hibernation image would contain all the data you'd need for accessing any encrypted partitions mounted at the time of hibernating.
We were talking about using the built-in encryption of uswsusp. Try again, player 2 ;-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hello, on Mittwoch, 13. Oktober 2010, Carlos E. R. wrote:
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ⁽¹⁾.
That should be avoidable ;-) Create a file containing the encryption key for /home (and another one for swap) on your root partition (needless to say: restrict access to root only). This file can directly be generated from /dev/random and serve as an *additional* key/password for the partitions - LUKS supports up to 8 (IIRC) keys/passwords per partition. To get you started: cryptsetup luksAddKey /dev/sda1 (handing over the key file is left as exercise to the reader ;-) man crypttab tells you that you can specify the key file in the third column of /etc/crypttab - those partitions can then be decrypted without entering the password at boot. On boot, you'll then only have to type the password for the root partition. (Choose a good password for it, because it will also give access to the other partitions.) For manual mounting of the other partitions, your password will still work. Note: This mail is IMHO and AFAIK - I do not have such a setup and therefore can't guarantee that it works. Regards, Christian Boltz --
[...] if the installation of a stupid package failed, [...] AFAIK there is no package named `stupid'. [> Raphael Schillings and Michael Gross in https://bugzilla.novell.com/show_bug.cgi?id=147588] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1010141323030.8680@Telcontar.valinor> On Thursday, 2010-10-14 at 01:38 +0200, Christian Boltz wrote:
Hello,
on Mittwoch, 13. Oktober 2010, Carlos E. R. wrote:
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ⁽¹⁾.
That should be avoidable ;-)
Create a file containing the encryption key for /home (and another one for swap) on your root partition (needless to say: restrict access to root only). This file can directly be generated from /dev/random and serve as an *additional* key/password for the partitions - LUKS supports up to 8 (IIRC) keys/passwords per partition. To get you started: cryptsetup luksAddKey /dev/sda1 (handing over the key file is left as exercise to the reader ;-)
The documentation about all this is, say, a little criptic :-) Additional password means that both keys have to be suplied to enter, or just any one of them? Yesterday night I thought you meant both, today I think you mean one of them. One is saved into a file in root, so that it doesn't ask for it, right? I see... Interesting.
Note: This mail is IMHO and AFAIK - I do not have such a setup and therefore can't guarantee that it works.
But I think I read about this somewhere before - only that now I understood :-) I like this method. What about swap and hibernation? If root is encripted, there has to be a plain /boot partition, so that the kernel can be loaded by grub - otherwise we need a grub that reads encripted filesystems. Ok, so assume /boot is plain. Root is encripted, swap too. Now after hibernation the kernel boots, and... who asks for the password to open the swap before reading the hibernated image? It is not using "uswsusp", it is the entire swap. Otherwise, we need to use "uswsusp". In that case, swap is plain, just the hibernated image is encripted. Do we then create two different swaps, one for each purpose? one plain for hibernation, one encripted for normal use? That's ugly, even if we discover how to configure such a thing. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky26RMACgkQtTMYHG2NR9V2lACfT5ongr/S4ngpYKKfMNC1NEVl xP0Anjrm8vBU1HM5xIQsX8AFPfBQXOHq =46tP -----END PGP SIGNATURE-----
Quoting Carlos E. R. (carlos.e.r@opensuse.org):
On Thursday, 2010-10-14 at 01:38 +0200, Christian Boltz wrote:
on Mittwoch, 13. Oktober 2010, Carlos E. R. wrote:
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ?¹?.
That should be avoidable ;-)
Create a file containing the encryption key for /home (and another one for swap) on your root partition (needless to say: restrict access to root only). This file can directly be generated from /dev/random and serve as an *additional* key/password for the partitions - LUKS supports up to 8 (IIRC) keys/passwords per partition. To get you started: cryptsetup luksAddKey /dev/sda1 (handing over the key file is left as exercise to the reader ;-)
The documentation about all this is, say, a little criptic :-)
Additional password means that both keys have to be suplied to enter, or just any one of them? Yesterday night I thought you meant both, today I think you mean one of them. One is saved into a file in root, so that it doesn't ask for it, right? I see... Interesting.
Note: This mail is IMHO and AFAIK - I do not have such a setup and therefore can't guarantee that it works.
But I think I read about this somewhere before - only that now I understood :-)
I like this method.
What about swap and hibernation?
If root is encripted, there has to be a plain /boot partition, so that the kernel can be loaded by grub - otherwise we need a grub that reads encripted filesystems.
Ok, so assume /boot is plain. Root is encripted, swap too. Now after hibernation the kernel boots, and... who asks for the password to open the swap before reading the hibernated image? It is not using "uswsusp", it is the entire swap.
Otherwise, we need to use "uswsusp". In that case, swap is plain, just the hibernated image is encripted. Do we then create two different swaps, one for each purpose? one plain for hibernation, one encripted for normal use?
That's ugly, even if we discover how to configure such a thing.
OK, I have a version of it up and running :-) It does not make use of uswsusp, though the suspend/resume swap would not need to be encrypted did I make use of uswsusp. I decided against this just because I was too lazy to dig into uswsusp, for no better reason. System now looks like this: - Plain /boot. (On memstick. Without memstick the laptop boots its first partition with an old Windows which does not recognize the linux partitions and does not show them. It's the second partition of the memstick by the way. A Windows user looking at my memstick will only see a standard-sized vfat partition with some unimportant files, like music or such.) It usually is *not* mounted. - Encrypted /root, /home, swap on harddisk. I used luks, supplied only key files for /home and swap (as they are needed only after /root has been unlocked), and supplied a human-typeable passphrase for /root. I had to make sure I know where to find the keyboard's keys for that, as the moment I am prompted for password german keyboard map is not yet active. That's a bit annoying... - encrypted suspend/resume swap on memstick (the third partition there). It's slow, so I do not want it active as swap during normal work. I use the same human-typeable passphrase as for /root, and an additional key-file. This partition can be unlocked by either the passphrase or the key file. I could have put that on the harddisk aswell. There was unused space on the memstick though, and it's the setup my boss wished for. It's his laptop... This swap usually is *not* active. - kernel boot parameters telling it to unlock /root and the suspend/resume swap upon booting. It's the initrd's scripts that prompt for passphrase for those two partitions. Then it either resumes or does full boot, depending on what is needed. In case of full boot, the other encrypted partitions are unlocked using the key files residing in the now unlocked /root. - For suspend to disk, I use a wrapper around powersave -U. It can be either called directly, or via the laptop's suspend-to-disk function key. This wrapper script * checks for and waits for the USB stick (maximum 10 seconds, after which it gives up) * mounts /boot in case it is not mounted * unlocks the suspend/resume swap partition in case it is not yet unlocked (here I need the key in the key file) * adds this suspend/resume swap partition to swap in case it is not yet active * calls powersave -U (rest of the script will not be executed until after resume) * removes suspend/resume swap partition from swap in case it had not been active before this script * removes suspend/resume swap partition from device mapper in case it was unlocked by this script * unmounts boot in case it was mounted by this script One thing I like with this setup is the fact that although /root and resume partitions need 'manual' unlocking, I only am prompted for one passphrase. This lowers the temptation to make the passphrase too short. (During tests I had a setup with the need of typing the passphrase 4 times for each boot. I was sorely tempted to reduce it to one-letter length ;-) In case people are interested in a step by step description of my solution, I can write it down. I have one for personal usage, but it's in german. I would need a place to publish it, though. A place where it will be found. Thanks a lot for all the help I received! Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Susan Dittmar wrote:
- encrypted suspend/resume swap on memstick (the third partition there). It's slow, so I do not want it active as swap during normal work. I use the same human-typeable passphrase as for /root, and an additional key-file. This partition can be unlocked by either the passphrase or the key file. I could have put that on the harddisk aswell. There was unused space on the memstick though, and it's the setup my boss wished for. It's his laptop...
I'm afraid memstick is still less reliable than the good old ferromagnetic plate. The security gained is 0. Slowdown is about 4 times for loading the hibernated image, I guess (considering reasonably new memstick)? Petr -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LNX.2.00.1010141323030.8680@Telcontar.valinor>
On Thursday, 2010-10-14 at 01:38 +0200, Christian Boltz wrote:
Hello,
on Mittwoch, 13. Oktober 2010, Carlos E. R. wrote:
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ⁽¹⁾.
That should be avoidable ;-)
Create a file containing the encryption key for /home (and another one for swap) on your root partition (needless to say: restrict access to root only). This file can directly be generated from /dev/random and serve as an *additional* key/password for the partitions - LUKS supports up to 8 (IIRC) keys/passwords per partition. To get you started: cryptsetup luksAddKey /dev/sda1 (handing over the key file is left as exercise to the reader ;-)
The documentation about all this is, say, a little criptic :-)
Additional password means that both keys have to be suplied to enter, or just any one of them? Yesterday night I thought you meant both, today I think you mean one of them. One is saved into a file in root, so that it doesn't ask for it, right? I see... Interesting.
Note: This mail is IMHO and AFAIK - I do not have such a setup and therefore can't guarantee that it works.
But I think I read about this somewhere before - only that now I understood :-)
I like this method.
What about swap and hibernation?
If root is encripted, there has to be a plain /boot partition, so that the kernel can be loaded by grub - otherwise we need a grub that reads encripted filesystems.
Ok, so assume /boot is plain. Root is encripted, swap too. Now after hibernation the kernel boots, and... who asks for the password to open the swap before reading the hibernated image? It is not using "uswsusp", it is the entire swap.
Otherwise, we need to use "uswsusp". In that case, swap is plain, just the hibernated image is encripted. Do we then create two different swaps, one for each purpose? one plain for hibernation, one encripted for normal use?
That's ugly, even if we discover how to configure such a thing.
- -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux)
iEYEARECAAYFAky26RMACgkQtTMYHG2NR9V2lACfT5ongr/S4ngpYKKfMNC1NEVl xP0Anjrm8vBU1HM5xIQsX8AFPfBQXOHq =46tP -----END PGP SIGNATURE----- Hello!
What about using a card reader instead of password input not possible to bypass keylogger or via a usb-stick to be removed after boot? Unfortionately I don't know if this may work with card reader at boot time already. Would be good to know;) Best regards Philippe -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 10:40 +0200, Susan Dittmar wrote:
Dear Carlos,
thanks for your answer.
Quoting Carlos E. R. ():
I don't like this method because I don't like LVM much.
Hm. I share your feelings towards LVM. But maybe I will try that nonetheless. I do not like LUKS either, because encrypting a partition and then writing in plain text most of the information how to decrypt it sounds like locking the door and then leaving information about how to obtain the key under the doormat. Nonetheless I already decided to use LUKS, mainly because I did not manage to make things run without.
It does not shove the key under the mat, it simply labels outside the manufacturer of the safe. I suppose a good thief knows the make of the safe just by looking at it, doesn't need the label. Plus, remember that this is open source, thus the encription method is published entirely. You don't loose safety by using LUKS, I believe.
The passphrase is gone when cryptsetup finishes.
Theoretically it could be kept in /proc/keys, right?
No use when resuming: it will be inside swap which you can not recover till the process knows the password.
Ah, you misunderstood. There's no problem with typing the passphrase for resuming. Problem is the suspend part -- here I would prefer to just have to press *one* key (the laptop's prebuilt function key) for the laptop to shut down. For this suspend to disk in my current setup I need to re-attach the needed swap space to the system, and this re-attachment needs the key.
No, I did not missunderstood. You want to enter the key just once, and I say that /proc/keys is not available on resume. I will post another idea on another post. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky1s1wACgkQtTMYHG2NR9Vz1QCeNGJk4GjO4db2VyT6YYg0B3o+ k6IAoJbwWprIuo6nvLVT8Dz92kkqRFbe =C0QY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Dear Petr, Quoting Petr Cerny (pcerny@suse.cz):
What about triggering the suspend process by media insert event (with the correct uuid). The script would search for specific data on the media - a key that would be used for encrypting the hibernation image to hard drive using the key from the memory stick. Upon boot from the memory stick, the key would be used to decrypt the image.
yes, that could be a path to follow. Thanks for this idea! I could even set up the encrypted swap on the fly, using one-use passphrases. Now I will have to find out how to tell the booting system where to find the passphrase for the resume disk independently of the other passphrases.
The passphrase is gone when cryptsetup finishes.
Theoretically it could be kept in /proc/keys, right?
Yes -- but I do not know how to access it in any way to then put it there or wherever it's convenient. Thanks, Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Quoting Ludwig Nussel (ludwig.nussel@suse.de):
But my boss wants to insert the memstick at boot time, then remove it as soon as booting is done. Then he wants to insert it again for supend to disk. In principle that's fine with me. The problem with this is that
Sounds cumbersome and error prone. What's wrong with suspending to the built in hard disk?
Well, that's what my first question was about. My boss thinks that the RAM-written-to-disk lacks in encryption. By the way, what would be the recomended way of calling suspend to disk? At least for the ThinkPads I tested on, standard installation (openSUSE 11.3) does *not* activate the corresponding function key, so I cannot look it up there. Thanks, Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Tue, 12 Oct 2010 14:53:25 +0200 Susan Dittmar <SDittmar@eureca.de> wrote:
Well, that's what my first question was about. My boss thinks that the RAM-written-to-disk lacks in encryption.
see my other mail.
By the way, what would be the recomended way of calling suspend to disk? At least for the ThinkPads I tested on, standard installation (openSUSE 11.3) does *not* activate the corresponding function key, so I cannot look it up there.
It depends. KDE or GNOME? In KDE, it also did not work for me for some reason, I guess the fn-f4 generated keycode is nonstandard. So I set up a keyboard shortcut in the KDE system config that calls a script "kdesuspendtoram.sh" which contains #!/bin/sh exec qdbus org.kde.kded /modules/powerdevil org.kde.PowerDevil.suspend 2 This makes sure that the KDE suspend action is used, which means: lock screen, disconnect network etc, and then suspend. Of course you want suspend to disk and not to RAM, which is probably done by a different number or a different org.kde.PowerDevil method. I don't know. plain "powersave -U" should also suspend to disk, but does not lock the screen (but since you are asking for the passphrase on resume, that should not matter that much). In GNOME, you should first try to configure it in gnome-power-manager preferences, but if that does not work, then gnome surely also offers a way to configure keyboard shortcuts to execute some command. Just do "powersave -U" from there. Good luck, Stefan -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds "Praktische Erfahrung ist viel Wert. Nur mal davon gehört zu haben, daß etwas nicht funktioniert, ist eine Sache - den GNOME Dateidialog selbst benutzt haben zu müssen, eine ganz andere." -- Steffen Winterfeldt I don't know why I dream this way The sky is purple and things are right every day I don't know, it's just this world's so far away But I won't fight, and I won't hate / Well not today "I personally just encourage people to switch to KDE. This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. [...]. Please, just tell people to use KDE." -- Linus Torvalds "[...] a 'enterprise desktop' should never be allowed to drive development. It is, by definition, boring and same-old, same-old." -- Linus Torvalds "You sure you software suspend guys haven't been hanging out with the IDE maintainers?" -- Rob Landley Never trust a computer you can't lift. You are storing 40 billion bits of information on a lump of metal and glass rotating at 10,000rpm and pushing into areas of quantum theory in order to store you data. It should be no suprise it might not be there a month later. -- Alan Cox "A lonely little useless module - no-one needs it, and it needs no-one else either. How sad." -- okir "Data security manager [...] presents new company security policy. It reads like a help text for a tax declaration" -- draht "I've never seen this before." "Its a blue light." "What does it do?" "Turns blue." "Mit Außerirdischen, die nicht weiter gekommen sind als Microsoft und Apple, will ich persönlich nichts zu tun haben." -- Prof. Harald Lesch -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Quoting Stefan Seyfried (stefan.seyfried@googlemail.com):
By the way, what would be the recomended way of calling suspend to disk? At least for the ThinkPads I tested on, standard installation (openSUSE 11.3) does *not* activate the corresponding function key, so I cannot look it up there.
It depends. KDE or GNOME?
Right now: text console, later: fvmw2. ;-) That's what the future user of the laptop is used to. Thanks for your answer though. Just a matter of time until the next laptop has to be setup for someone prefering KDE or GNOME. powersave -U is what I use right now. Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Wed, 13 Oct 2010 11:12:36 +0200 Susan Dittmar <SDittmar@eureca.de> wrote:
Quoting Stefan Seyfried (stefan.seyfried@googlemail.com):
By the way, what would be the recomended way of calling suspend to disk? At least for the ThinkPads I tested on, standard installation (openSUSE 11.3) does *not* activate the corresponding function key, so I cannot look it up there.
It depends. KDE or GNOME?
Right now: text console, later: fvmw2. ;-) That's what the future user of the laptop is used to.
OK. The hotkeys are handled by the user's session power management programs. In KDE that's powerdevil (with an apparent bug, which is why I had to set up an "execute command" hotkey that runs the mentioned script). For GNOME, that's gnome-power-manager. For text console, there is still acpid, where you can hook up your own events but it is not configured by default. For fvwm2, it is maybe best to just start some system-tray-simulating applet that then can run gnome-power-manager.
Thanks for your answer though. Just a matter of time until the next laptop has to be setup for someone prefering KDE or GNOME. powersave -U is what I use right now.
powersave -U in the end does only a dbus call, in the end "pm-hibernate" is called via HAL or whatever the power-management-solution-of-the-week is right now. The elegance of "powersave -U" is, that it can be called as a normal user, while pm-hibernate can only be run as root. good luck :-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 12:42 +0200, Stefan Seyfried wrote:
powersave -U in the end does only a dbus call, in the end "pm-hibernate" is called via HAL or whatever the power-management-solution-of-the-week is right now. The elegance of "powersave -U" is, that it can be called as a normal user, while pm-hibernate can only be run as root.
Ah! I was going to ask about that. You answered my question. I'll try powersave just now. [...] Yep, it worked. I stopped using it in perhaps 11.0 because it did not work, I think it checks somewhere to see if it should work or not, thought not, and refused. I don't remember now why, long ago. Probably wrote a bugzilla. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky1yMcACgkQtTMYHG2NR9UhAwCcDkHssqzSAVnSnInp91HtZluP /AoAoIxlb/M0N0yP2ccEhwWOwTZzh+IE =B6YN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Quoting Ludwig Nussel (ludwig.nussel@suse.de):
Susan Dittmar wrote:
On an openSUSE 11.3 laptop, I set up all hard disk partitions (in the easiest case just root and swap) as encrypted partitions using luks as described in http://en.opensuse.org/SBD:Encrypted_root_file_system
Uh, that article should probably be removed. The preferred method to have an encrypted root is to just click the checkbox in yast during installation.
I strongly speak against removing that article -- at least until YaST supports encryptet root! After reading your post yesterday I again tried encrypting root via YaST, and YaST refused. In case Carlos is right about the only way to do it with YaST being using encrypted LVM, then at least YaST should tell so in its refusal note. As I do not like LVM either, I still would appreciate articles like this one to remain there as long as YaST cannot do the appropriate steps on its own. Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 11:50 +0200, Ludwig Nussel wrote:
Susan Dittmar wrote:
Uh, that article should probably be removed. The preferred method to have an encrypted root is to just click the checkbox in yast during installation.
Certainly not removed. Just update to add the preferred current method, but leave the article because sometimes Yast doesn't work and people need alternatives. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky1ya0ACgkQtTMYHG2NR9X6RQCbBeiF5Vb8ILT3MKE0q0B3/3iP NHEAoIUwipE3gO+WwdXW4hPjIgF9VBm/ =mJcS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (9)
-
Arjen de Korte -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Ludwig Nussel -
Petr Cerny -
Philippe Vogel -
Stefan Seyfried -
Susan Dittmar