-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 14:20 +0200, Petr Cerny wrote:

Ludwig Nussel wrote:

...

...

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.

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

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. -- 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

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

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

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. -- 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

On Wed, 13 Oct 2010 18:15:11 +0200 (CEST) "Carlos E. R." 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

Stefan Seyfried wrote:

On Wed, 13 Oct 2010 18:15:11 +0200 (CEST) "Carlos E. R." 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

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

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

Carlos E. R. schrieb:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

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

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

On Tue, 12 Oct 2010 14:53:25 +0200 Susan Dittmar 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

On Wed, 13 Oct 2010 11:12:36 +0200 Susan Dittmar 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

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