Re: Back to the future.

["Indan Zupancic" <indan@nul.nu>]

Hello,

On Sat, May 5, 2007 11:16, Pavel Machek wrote:
>> But the same functionality can be achieved by doing:
>>
>> 1) Define a user password (e.g. /etc/shadow thing). (Once)
>>
>> 2) When a user logs in: get random data and encrypt it with the password,
>> this becomes the AES key. Store both the data and key in a secure way in
>> memory, e.g. using the existing kernel key infrastructure.
>
>
>
>> Advantage of this scheme is that it only need AES and can be done (mostly)
>> in kernel space. It's also faster and simpler than the current RSA scheme.
>> Disadvantage is that it wastes at least 32 bytes of memory when the system
>> is running, to store the data and key.
>
> Another disadvantage is that you need to hack into PAM infrastructure,
> that your suspend password needs to be same as someone's login
> password, and that it will really only work with single-user machine.

The first two are only true if you want to integrate it with user login, so
that a user only needs to sign in once, which seems like a convenient thing.
But if you don't want to integrate with the existing login infrastructure,
then just don't. And those disadvantages are true for any system that wants
users to login once.

Then the disadvantage is reduced to a user needing to provide the password
at suspend if the system wasn't booted from a snapshot. But no need for
users to generate any files, just to choose a resume password.

If the resume key is stored per user instead of a single global instance, it
will work with a multi-user system too. A more interesting question is what
should happen when one user did the suspend and the other wants to resume.
Throw away the snapshot? Refuse booting? Or boot and switch "active user"?

If you don't want people to resume each other's suspends then a key per user
works. If you want them to, then it becomes a bit tricky, especially if you
don't integrate with the login system. You don't want that a user can resume
someone else's snapshot and have access to everything that other user left
open. Nor do you want users to give a password twice.

If you want users to be able to resume each other's snapshots, you probably
also want the system to switch users after the resume. No matter what scheme
is used, this becomes hairy and hard to get watertight. (Perhaps "impossible"
is more realistic: how to be able to read the suspend image and copying it
to RAM again, without having access to all data within?)

But if it's an "us" against "them" case, and you want users to resume each
other's snapshots, you're right that the scheme I proposed will fall apart.
In which case it needs to be adjusted a bit to handle this case:

Have one global suspend/resume key, and for each user store it on disk,
encrypted with that user's password. Also store the key in memory as
before. Now when the system is suspended any user needs to have provided
his password once for everyone to be able to suspend without giving a
password. Also everyone can resume, if they have access to the file with
the list of encrypted keys and provide the right password. (Notice that
this looks more like the current scheme, where the private part of the
RSA key is encrypted with a passphrase and all stored in a file.)

Though it seems that using suspend to disk on a real multi-user system is
always asking for problems, because the suspend image may contain valuable
data which shouldn't be thrown away, but easily can by other users. Nor do
you want users to claim the machine, so it's a lose/lose situation. Also
with resume every user effectively gets root access, because of all the
memory access. So inter-user security is down the drain anyway.

Only sane usage I can see is when the users trust each other, in which case
they can as well agree on one resume password. ;-)

Greetings,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/