On Monday 06 April 2015 20:17:38 Pavel Machek wrote: > On Mon 2015-04-06 15:29:57, Pali Rohár 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). > > Actually... is the list of sites where the process wait small > enough? Could we modify them to be freezeable? Suspend should > work even if user stopped the his crypto partitions... > > Pavel If you suspend dm device and then you want to read file from fs which is on that device, then process freeze and you even cannot kill it with SIGKILL. Before entering suspend kernel tries to do sync and that operation also fails... -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
