[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data
arno at wagner.name
Sun Dec 30 11:53:08 CET 2012
On Sun, Dec 30, 2012 at 10:39:43AM +0100, Milan Broz wrote:
> On 12/30/2012 09:42 AM, Sven Eschenberg wrote:
> > Hi Milan,
> > What happens though, if signatures are not accessible during luksFormat?
> > (Or alternatively, are not found, because they are misaligned from the
> > current setup's perspective?)
> > Scenario, create a md volume with 1.0 metadata (end of device), start md
> > device, do luks format.
> Well, there are priorities but in fact these configurations need some
> external info (or admin knowledge).
Indeed. Just added the warning that previosuly used partitions should
be wiped to the man-page of cryptsetup. I also found that "wipefs"
does not remove matadata 0.90 signatures from md components (located
at the end. I still use them because I like kernel-level autodetection
and my arrays are small), also added warning about that.
> > Now, in intial unused state, the luks header and md metadata is visible.
> > While cryptsetup might be able to realize that the md device should first
> > be started, this might not be true for all tools (unfortunately). Possible
> > similiar scenarions with leftover superblocks etc. can surely be created.
> Yes, and in the MD format (end of device) case the problem repeats
> very often.
Indeed. See above.
> > I am aware this is a specific case due to the end of device policy of the
> > md metada v1.0. What I am trying to say is, not all cases can
> > automagically be resolved, sometimes the knowledge and interaction of an
> > admin might really be required. And for educated guessing, the admin needs
> > to be educated beforehand ;-).
> Yes, fully agree. I can mention other situations, which can be configured
> this way (LVM has several such undocumented scenarios) where you cannot
> automatically say which signature is the first...
I think warning the user that anything previously used need to be
cleaned is enough. FAQ and man-page do that now. I think that is
enough. Those that do not read documentation will always find some
way to shoot themselves in the foot...
> (I can write very long description about plans about "block device
> assembly" library under util-linux project which should help to solve
> this, but I am afraid that I will not work on this project anymore.)
Some magic pressure-cooker you throw some partitions in and
get some assembled and runnign filesystems out? Sounds like
a nightmare to implement ;-)
> And because we are on dmcrypt list - there is always need from security
> (or paranoid ;) people to separate or hide metadata (e.g. LUKS header or
> hidden container). In this situation you simply must know some info in
> advance to properly activate such storage...
Security requires understanding what you are doing or at least reading
the documentation carefully (it it is any good). For example, I
recently found out that there are people that run TrueCrypt on Windows
whith hibernation active and the hibernation file not on an encrypted
device. That is a complete fail, as the encryption keys then go into
the hiberfile. (The documentation warns about this.) Seems you can
even buy software that recovers the keys automatically.
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
More information about the dm-crypt