Bug 247794

What happens to the regular ram in suspend to disk?  As in there is not much
point in encrypting your swap partition if the ram is then written without
encryption to the disk.  

(In reply to comment #1)
> What happens to the regular ram in suspend to disk?  As in there is not much
> point in encrypting your swap partition if the ram is then written without
> encryption to the disk.  

You did not read carefully what I wrote.

I would expect that, on suspend-to-disk, a new, _password_ encrypted, swap is
created.
On resume, the password will be needed to complete the operation.

In this respect, in theory, it does not matter how the normal swap is working.

Nevertheless, I could imagine situations in which things may not work, for
example RAM and swap full, then suspend-to-disk with swap re-creation...

For this setup, you should not create the swap partition with a random
password, but just do the setup with a known password. Then just enter this
password on hibernate bootup and be done.

AFAIK this is no bug and we should close this bz.

Comments?

regards,

Florian La Roche

(In reply to comment #3)
> For this setup, you should not create the swap partition with a random
> password, but just do the setup with a known password. Then just enter this
> password on hibernate bootup and be done.

I respectfully disagree... :-)
There are several issues with this suggestion:

1) The random key is intrinsically more secure than a password, since nobody
knows it and eventually it could be pretty random (HW rng).
2) I do not want to type a password at each boot up, just because, maybe, I'll
suspend-to-disk later. Only if I decide to do it (suspend), a password should be
requested and used.
3) It does not work (I just checked). Since the kernel tries to resume from swap
before the encrypted partition is created/enabled. That is, /dev/mapper/swap
does not exists when the kernel has to decided the resume. Which means that
something in the ramdisk image (initrd) should create/recover the encrypted swap.

Maybe this report does not really belong to initscripts, nevertheless I see some
missing bits here and there in order to get a proper encrypted system.

I guess several pieces will need reworking in order to get this nailed down.

Anyway thanks for the understanding.

pg

1) if you enter a key when you try to hibernate the key won't be random anymore,
right ?
 But on the other hand adding a new key to the LUKS partition and removing it
after resume shouldn't be that difficult as long as we're below the 8 key (I
think) limit on the LUKS partition.
2) security doesn't come without a price. I'd suggest you'll take a look at bug
# 124789 and check out the howto referenced in comment #95. This will give you
encrypted swap and encrypted logical volumes and requires just one single key
instead of one for each partition.
The very same bugzilla has a long list of attachements, take the one with the id
161909 and apply it (make sure to have backups and maybe a rescue CD). You'll
need these patches to make full use of encryption.

(In reply to comment #5)
> 1) if you enter a key when you try to hibernate the key won't be random anymore,
> right ?

It seems to me there is some confusion about use cases.
The swap is _always_ needed and, eventually, used. So, it is better, IMHO, to
provide a more shielded approach. Not to mention the password thing at each
boot, which I would really find annoying.
The suspend case, instead, is something _optional_, eventually useful, but not
necessarily always to be used.
Of course the password will not be random for the suspend-to-disk, but that's
the price to pay when deciding to S2D, which, as wrote above, is optional.

>  But on the other hand adding a new key to the LUKS partition and removing it
> after resume shouldn't be that difficult as long as we're below the 8 key (I
> think) limit on the LUKS partition.

The point is that I don't think is realistic to ask for a swap password each
time the machine boots. Of course, one idea could be, as you suggested below, to
use a single password for all partitions, but, again, I would prefer a random
key for the swap (as swap, not S2D storage).
I could imagine a solution with two swaps, one real, one for S2D.

> 2) security doesn't come without a price. I'd suggest you'll take a look at bug
> # 124789 and check out the howto referenced in comment #95. This will give you
> encrypted swap and encrypted logical volumes and requires just one single key
> instead of one for each partition.

Actually, I would prefer one key for each partition... :-)
At least a key request for each protected area, if we have to think about
security... So it would be possible to selectively enable the needed parts, but
that's not he point here.

> The very same bugzilla has a long list of attachements, take the one with the id
> 161909 and apply it (make sure to have backups and maybe a rescue CD). You'll
> need these patches to make full use of encryption.

This seems to me a bit out of scope.
The encrypted swap is needed in order to lock-out _temporary_ information from
being re-read by someone else.
The use case is not a complete encrypted system (not necessarily, at least), but
a user safe system, where the user should not bother to leave things around,
since the persistent temporary storage is locked.
For example, the encryption should also apply to /tmp, or, like I'm doing now,
use tmpfs for /tmp (so, no persistence), since current encryption framework does
not work for /tmp (there is even a bug open for that).

In this context, the swap must be encrypted in order to avoid leakage of
information, but this does not mean all the rest should be encrypted too.
Is just a safety precaution which should not affect a normal user, but simply
improve security.

So, the expectation is to have encrypted swap, with S2D capabilities, with
minimum user interaction.

In other word, we should improve security without making things more complicated
than needed, if not requested.

Hope this clarifies the issue.

BTW, thanks for the support and the suggestions.

pg

I successfully resumed from a LUKS-encrypted swap partition by entering the
password during boot.  I needed to use the encryption-aware mkinitrd from bug
124789 comment 118, which I modified slightly to include the module for lrw
encryption.  (With the original mkinitrd, the machine failed to resume and then
booted newly.)  This is to say, the encryption-aware mkinitrd fixes issue 3)
from comment #4.

IMO, this form of suspend-to-encrypted-swap should be fine for most Fedora users
and support for a more complex setup with a password established at suspend time
doesn't need to be an integral part of
http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems .

So, if I understand correctly, the proposed solution, with LUKS, should work as
follow:

A) At normal boot, an encrypted swap is created, with random password, using LUKS.
This will guarantee maximum confidentiality in any case (will it?).

B.1) When Suspending-To-Disk, a password is requested and added to the LUKS swap
partition passwords (max 8, but this should not matter, see below).

B.2) At resume, the password is requested and used to continue the operation.

Questions:

1) What about the swap after resume? Will this work with the original
certificate, unlocked by the user password, or will it be re-created? Does this
matter at all? I mean, after resume, is the swap as secure as at boot (random
password only) or not (user password may be weaker than the random one)?

2) What about consecutive S2Ds? Should  the user password always be added in the
second (or first) slot of LUKS (thus removing the old one or the random one)? I
I guess it is not acceptable to have only 7~8 S2Ds...

3) In case of failure to provide the password, I assume the system should go to
case A), shouldn't it?

Thanks for your attention.

pg

 a) correct
b1) correct
b2) correct with the addition that the password needs to be removed from the list
    of the LUKS swap partition passwords

1) swap will work with the original certificate, the user password isn't valid
anymore (see b2). But there seems to be a misunderstanding what swap encryption
actually does. Please note that swap appears to be unencrypted from the user
point of view as long as the machine runs, encryption comes into play when you
pull the power plug or shut down the computer in some other, unclean way. If
then someone tries to access the data on the disk, it will be encrypted. This is
the same for encrypted filesystem partitions, as long as the machine is running
the data is looks like it is unencrypted and encryption only comes into play
when you reboot or try to access the data after plugging the disk into another
machine.
2) The slot doesn't matter, there just needs to be one free slot for the S2D
password. It will be freed again after resume.
3) This still needs to be decided. It's more secure to go to case a), but maybe
you don't want to loose some of your work and start exactly where you've
suspended to disk even when you entered the wrong password by mistake. But this
raises another question: How do you get a normal boot when you've forgotten the
S2D password ?

Thanks for the answer.

About Q3, I guess a certain number of trials should be allowed, then the system
will have to reboot as it was not in S2D.
If the password is lost... It is lost... Any post-failsafe feature will be a
security breach, I guess.

The question might be (Q4): what if another user needs to use the PC?
Would it be possible to allow each user to unlock the swap? Eventually with
something like the "fast user switch" case for gnome: user Bob S2D, user Alice
resumes. A valid login/pass is requested and then the swap is unlocked. Assuming
at S2D to have an automatic display lock, of course.
Would it make sense to do so?

About erasing the password. It would be more convenient, IMHO, to add this
feature to LUKS, i.e. a use-once password, in order to be more "atomic" in the
unlock -> erase operations. In case Q4 is impossible...

Final comment: of course the swap will appear unencrypted at runtime, actually
it will be so for all users logged into the machine. I guess it is clear that
the use case here is a powered off or S2D PC, not a running one.

Thanks again for your attention.

I think the problem here is suspending to swap is fundamentally broken. We
should be suspending to a filesystem instead. suspend2 or TuxOnIce or whatever
its called these days can do this.

What is wrong with suspend to swap?  For some time now, I have been successfully
suspending to a swap partition inside an LUKS-encrypted LVM physical volume
(using a password established when I installed the system, not one established
on each suspend as Piergiorgio is proposing).

Piergiorgio, after rereading the discussion, I think I appreciate your use case
better.  However, resuming from encrypted swap does "work" for me using a fixed
password entered on every boot (with mkinitrd-6.0.30-1.fc9).  If this bug is to
remain open for your more complex approach, please narrow the summary
accordingly, and Fedora should reevaluate whether to include the bug in
FeatureEncryptedFilesystems and whether it blocks bug 326611.

(In reply to comment #13)
> Piergiorgio, after rereading the discussion, I think I appreciate your use case
> better.  However, resuming from encrypted swap does "work" for me using a fixed
> password entered on every boot (with mkinitrd-6.0.30-1.fc9).  If this bug is to
> remain open for your more complex approach, please narrow the summary
> accordingly, and Fedora should reevaluate whether to include the bug in
> FeatureEncryptedFilesystems and whether it blocks bug 326611.

I'm a bit confused, are you taking care of this issue or Bill Nottingham?
Because it is assigned to him.

Anyway, I see a problem here, which is the multi-user case.
Considering that we have the fast-user-switch thing, it is not unrealistic, I
guess, that one user boots, enters a password for the swap and then another user
S2D.
In this situation the resume is impossible for the second user.

Not to mention the inconvenience of entering a password each boot, which will
end up with 1234 as password.

What about the proposal of Comment #5? To difficult?

Which new Summary do you propose, in order to clarify the issue?
Should we point out the multi-user case?

What about the Fedora version? Do we need to change it to 9?

Thanks,

pg

(In reply to comment #14)
> I'm a bit confused, are you taking care of this issue or Bill Nottingham?
> Because it is assigned to him.

I'm not taking care of the issue; I'm only commenting on it.

> Anyway, I see a problem here, which is the multi-user case.
> Considering that we have the fast-user-switch thing, it is not unrealistic, I
> guess, that one user boots, enters a password for the swap and then another user
> S2D.
> In this situation the resume is impossible for the second user.

Under my approach, each user would set a password in his/her own LUKS key slot
of the swap partition beforehand.  Then, when a user boots or resumes the
computer, he/she unlocks the swap with his/her own password.  There is no problem.

> Not to mention the inconvenience of entering a password each boot, which will
> end up with 1234 as password.

I could see that happening if the password were *established* on each boot, but
not if a user is providing a preestablished password (which could be plenty
strong) to unlock the swap.

> What about the proposal of Comment #5? To difficult?

This is the single-user case with a password established on each suspend and
supplied on each resume?  I imagine it would be doable:

1. Set aside a partition for encrypted swap.
2. Get an initrd that attempts to luksOpen the partition and resume from the
swap inside.  If the partition isn't recognized as LUKS, I assume this step will
fail but the boot will continue.  The Fedora 9 mkinitrd might do this for you
out-of-the-box.
3. Add a block of code to rc.sysinit to handle the remaining boot/resume-time
actions.  If the partition isn't open (a fresh boot), the code luksFormats it
with a random key and a random password stored (say) in /tmp/swap.pass, opens
it, formats the inside as swap, and enables the swap.  If the partition is
already open, the code deletes the old password.
4. Add code to pm-hibernate that prompts you to set a password and adds it to
the partition, giving the password in /tmp/swap.pass to "cryptsetup luksAddKey"
so it can obtain the unencrypted partition key.

The /tmp/swap.pass password makes it possible to get at the partition key at
hibernate time because I don't know of any easy way to pull the key out of the
kernel.  This password changes on every fresh boot but can stay the same across
any number of suspends-to-disk; /tmp is part of the encrypted swap, so the file
presents no vulnerability.

So the proposal is doable, but I don't know if Fedora considers it important
enough to do it now that the basic predetermined-password case works.  You could
always implement it for yourself.

> Which new Summary do you propose, in order to clarify the issue?
> Should we point out the multi-user case?

The best concise summary I could come up with for the single-user case is
"Support establishing encrypted-swap password on each suspend".  I'm not sure
what you're proposing for the multi-user case.

> What about the Fedora version? Do we need to change it to 9?

Sure.

(In reply to comment #15)

> I'm not taking care of the issue; I'm only commenting on it.

Ah! OK!

> Under my approach, each user would set a password in his/her own LUKS key slot
> of the swap partition beforehand.  Then, when a user boots or resumes the
> computer, he/she unlocks the swap with his/her own password.  There is no problem.

Sorry, now I do not follow you anymore.
You mean something like putting there the user(s) login password (or another
one, but that one would be really nice)?
But the LUKS can support only up to 8, I guess, different passwords, this would
limit to max 8 users.
Or maybe I did not fully understand your proposal.

> I could see that happening if the password were *established* on each boot, but
> not if a user is providing a preestablished password (which could be plenty
> strong) to unlock the swap.

OK, I would say I like the concept of using an *unlock* password for each user,
since this will, maybe in the future, allow a user switch at resume.
But still I do not understand how can this support more than 8 users.

> This is the single-user case with a password established on each suspend and
> supplied on each resume?  I imagine it would be doable:

Yep, with the limitation that only the user doing the S2D can resume.

> 1. Set aside a partition for encrypted swap.
> 2. Get an initrd that attempts to luksOpen the partition and resume from the
> swap inside.  If the partition isn't recognized as LUKS, I assume this step will
> fail but the boot will continue.  The Fedora 9 mkinitrd might do this for you
> out-of-the-box.

Good!

> 3. Add a block of code to rc.sysinit to handle the remaining boot/resume-time
> actions.  If the partition isn't open (a fresh boot), the code luksFormats it
> with a random key and a random password stored (say) in /tmp/swap.pass, opens
> it, formats the inside as swap, and enables the swap.  If the partition is
> already open, the code deletes the old password.

Uhm, password in /tmp?

> 4. Add code to pm-hibernate that prompts you to set a password and adds it to
> the partition, giving the password in /tmp/swap.pass to "cryptsetup luksAddKey"
> so it can obtain the unencrypted partition key.
> 
> The /tmp/swap.pass password makes it possible to get at the partition key at
> hibernate time because I don't know of any easy way to pull the key out of the
> kernel.  This password changes on every fresh boot but can stay the same across
> any number of suspends-to-disk; /tmp is part of the encrypted swap, so the file
> presents no vulnerability.

I guess the idea was to add/remove user passwords to the LUKS header, so no need
of an external one.
If I got it correctly...

> So the proposal is doable, but I don't know if Fedora considers it important
> enough to do it now that the basic predetermined-password case works.  You could
> always implement it for yourself.

Well, of course, but maintaining it is a bit out of my possibilities... :-)
 
> The best concise summary I could come up with for the single-user case is
> "Support establishing encrypted-swap password on each suspend".  I'm not sure
> what you're proposing for the multi-user case.

I was under the impression the multi-user case needed some more work, but it
seems it is not the case.

> > What about the Fedora version? Do we need to change it to 9?
> 
> Sure.

This I'll do it after installing it and verifying the problems... :-)

So, OK, I'll change Summary together with Fedora version as soon as I'll have
the chance to try F9.

Thanks for all the suggestions and explanations, I learned a lot!

pg

(In reply to comment #16)
> > Under my approach, each user would set a password in his/her own LUKS key slot
> > of the swap partition beforehand.  Then, when a user boots or resumes the
> > computer, he/she unlocks the swap with his/her own password.  There is no
problem.
> 
> Sorry, now I do not follow you anymore.
> You mean something like putting there the user(s) login password (or another
> one, but that one would be really nice)?

It could be the login password or something else.  The point is to preestablish
a set of passwords such that each person who needs to boot/resume the computer
knows at least one of the passwords.

> But the LUKS can support only up to 8, I guess, different passwords, this would
> limit to max 8 users.

Correct.  Any scheme based on LUKS is going to have this 8-password limit.  If
you have more than 8 users, you could just have some of them share a single
password, or if you don't like that, modify cryptsetup to use a format that is
like LUKS but has more password slots.

> I guess the idea was to add/remove user passwords to the LUKS header, so no need
> of an external one.

"Adding a password" really means "adding an encryption of the partition key with
that password".  To do that, you first need to have the partition key. 
"cryptsetup luksAddKey" achieves this by asking you for an existing password and
decrypting an existing key slot to get the partition key.  The purpose of
/tmp/swap.pass is to supply such an existing password.  Without this file, the
only way to get the partition key would be from the kernel (which is using it to
read and write the partition), but I don't know of an easy way to do that.

> Uhm, password in /tmp?

What's wrong with it?  When the machine is off, /tmp is inside the encrypted
swap, so an intruder couldn't read the password unless he already knew the
password to open the swap--no vulnerability there.  When the machine is running,
it does no harm for root to read the password since root could just read the
swap directly, and file permissions can be set to prevent non-root users from
reading the password.

Oops, I left one thing out of my design in comment #15:

5. Add an initscript that obliterates the LUKS header of the swap partition on
shutdown so that the machine doesn't try to open the partition on the next boot.

At this point, I don't think this is the sort of thing we'd integrate in
initscripts proper - you'd want this handled at a higher level than just
prompting for a password from a pm-hibernate script, and this is a more fringe
usage case.

Closing as currentrelease - resume from encrypted swap *does* work for the cases
that we do set up. If you've got a specific proposal, opening up a new RFE may
be useful.