[pkg-cryptsetup-devel] Bug#587222: Bug#587222: Bug#587222: cryptsetup does not/cannot close dm-crypt devices, if root-fs is on it, but does also not warn about it

[Christoph Anton Mitterer]

On Sun, 2010-06-27 at 00:34 +0200, Jonas Meurer wrote:
> To be honest, I don't like the idea of using the bug tracking system
> as
> a discussion archive. As maintainer, I like to keep the count of open
> bugs against packages low. It's generally better to document
> controversial topics in the package or at documentation pages.
Well,... actually it is a bug,.. it's however probably not limited to
Debian itself.


> Maybe it's time to setup a cryptsetup wiki page at wiki.debian.org,
> which documents all these discussion we have. I don't have the time to
> maintain it, so feel free to setup, as long as mention all arguments,
> and try to keep the documentation neutral ;-)
Don't think that a wiki will help much, as it's a development issue,.. I
guess that we have to bring all "affected" maintainers (at least
lvm2,mdadm,dm-crypt) to one table.
I was about to write an email to all you guys,... describing the problem
in detail, and asking what everybody would like to do,... but I can of
course skip you if you're currently not interested.


> this is a real problem, and I'm glad that you started the discussion
> at the linux kernel mailinglist. It would be great to fix the shutdown
> process in debian in a way that all keys are wiped from memory.
If you're glad I don't understand why you dislike this bug...


> both init scripts tell you that the to-be-stopped dm-crypt device is
> still busy. Just run '/etc/init.d/cryptdisks stop' on your running
> system to see what happens:
> 
> Stopping early crypto disks...cswap1 (busy)...ctemp1 (busy)...clvm1
> (busy)...done.
Ah ok,.. I know why I didn't notice... it seems you don't let the
initscript action fail, if some were still busy. lvm2 does,.. so I see
the big red "failed" ;)


> I think that this already became clear in the discussion: remount,ro
> should be enough to prevent data loss. But it's not enough security
> wise, as the dm-crypt key still is in memory.
Yes....


> Next cryptsetup package upload should fix the boot/halt order of
> cryptdisks(-early) initscripts for non-root encryption. But I don't
> know
> a solution for encrypted root devices, and I've never heard about
> haltramfs or something like that.
I guess the best idea is if we discuss the security thingy for
root-devices at lkml.


May I propose, that if doing cryptdisks-[early] stop,... and some
devices could not be stopped, you give an status of failure back.
Then it will be more clear that this action has failed,... and I guess
we can close this bug.



Cheers,
Chris.