On 04/17/2015 09:52 AM, Mike Snitzer wrote:
On Thu, Apr 16 2015 at 5:23am -0400,
Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
Mike Snitzer wrote:
On Thu, Apr 09 2015 at 9:28am -0400,
Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
On Thursday 09 April 2015 09:12:08 Mike Snitzer wrote:
On Mon, Apr 06 2015 at 9:29am -0400,
Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
On Monday 06 April 2015 15:00:46 Mike Snitzer wrote:
On Sun, Apr 05 2015 at 1:20pm -0400,
Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
This patch series increase security of suspend and hibernate
actions. It allows user to safely wipe crypto keys before
suspend and hibernate actions starts without race
conditions on userspace process with heavy I/O.
To automatically wipe cryto key for <device> before
hibernate action call: $ dmsetup message <device> 0 key
wipe_on_hibernation 1
To automatically wipe cryto key for <device> before suspend
action call: $ dmsetup message <device> 0 key
wipe_on_suspend 1
(Value 0 after wipe_* string reverts original behaviour - to
not wipe key)
Can you elaborate on the attack vector your changes are meant
to protect against? The user already authorized access, why
is it inherently dangerous to _not_ wipe the associated key
across these events?
Hi,
yes, I will try to explain current problems with cryptsetup
luksSuspend command and hibernation.
First, sometimes it is needed to put machine into other hands.
You can still watch other person what is doing with machine, but
once if you let machine unlocked (e.g opened luks disk), she/he
can access encrypted data.
If you turn off machine, it could be safe, because luks disk
devices are locked. But if you enter machine into suspend or
hibernate state luks devices are still open. And my patches try
to achieve similar security as when machine is off (= no crypto
keys in RAM or on swap).
When doing hibernate on unencrypted swap it is to prevent leaking
crypto keys to hibernate image (which is stored in swap).
When doing suspend action it is again to prevent leaking crypto
keys. E.g when you suspend laptop and put it off (somebody can
remove RAMs and do some cold boot attack).
The most common situation is:
You have mounted partition from dm-crypt device (e.g. /home/),
some userspace processes access it (e.g opened firefox which
still reads/writes to cache ~/.firefox/) and you want to drop
crypto keys from kernel for some time.
For that operation there is command cryptsetup luksSuspend, which
suspend dm device and then tell kernel to wipe crypto keys. All
I/O operations are then stopped and userspace processes which
want to do some those I/O operations are stopped too (until you
call cryptsetup luksResume and enter correct key).
Now if you want to suspend/hiberate your machine (when some of dm
devices are suspeneded and some processes are stopped due to
pending I/O) it is not possible. Kernel freeze_processes function
will fail because userspace processes are still stopped inside
some I/O syscall (read/write, etc,...).
My patches fixes this problem and do those operations (suspend dm
device, wipe crypto keys, enter suspend/hiberate) in correct
order and without race condition.
dm device is suspended *after* userspace processes are freezed
and after that are crypto keys wiped. And then computer/laptop
enters into suspend/hibernate state.
Wouldn't it be better to fix freeze_processes() to be tolerant of
processes that are hung as a side-effect of their backing storage being
suspended? A hibernate shouldn't fail simply because a user chose to
suspend a DM device.
Then this entire problem goes away and the key can be wiped from
userspace (like you said above).
Still there will be race condition. Before hibernation (and device
poweroff) we should have synced disks and filesystems to prevent data
lose (or other damage) as more as we can. And if there will be some
application which using lot of I/O (e.g normal firefox) then there
always will be race condtion.
The DM suspend will take care of flushing any pending I/O. So I don't
see where the supposed race is...
Anything else that is trapped in userspace memory will be there when the
machine resumes.
So proper way is to wipe luks crypto keys *after* userspace processes
are freezed.
I know you believe that I'm just not accepting that at face value.
Um, pardon me if I'm being naive, but what about the case of hibernation
where the swapdev and the root device are both LVs on the same dm_crypt
device?
The kernel is writing to swap _after_ userspace processes are all frozen;
that seems to me like an ordering dependency entirely incompatible with
userspace dropping the key...
Good point, definitely not compatible with the Pali's approach.
Ouch! I'm afraid this effectively killed one of my experiments with
dm-crypt suspend. Good to get reminded sooner than later!
(but is swap really configured ontop of the same dm-crypt device like
this in practice? I've not heard of that being a common pattern but I
could just be sheltered)
yes. It's one among many perfectly valid setups.
(For some the goal here would be to have whole disk encrypted including
boot partition unlocked during boot)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
