From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data
Date: Sun, 30 Dec 2012 11:53:08 +0100 [thread overview]
Message-ID: <20121230105308.GA13288@tansi.org> (raw)
In-Reply-To: <50E00BDF.2000109@gmail.com>
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
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@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
next prev parent reply other threads:[~2012-12-30 10:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-27 6:12 [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data Emily Williams
2012-12-27 9:35 ` ken
2012-12-27 9:52 ` Arno Wagner
2012-12-28 14:46 ` Sven Eschenberg
2012-12-28 15:04 ` Arno Wagner
2012-12-28 19:22 ` Milan Broz
2012-12-29 7:06 ` Arno Wagner
2012-12-29 9:05 ` Milan Broz
2012-12-29 11:52 ` Arno Wagner
2012-12-30 8:42 ` Sven Eschenberg
2012-12-30 9:39 ` Milan Broz
2012-12-30 10:53 ` Arno Wagner [this message]
2012-12-30 12:08 ` Sven Eschenberg
2012-12-30 12:25 ` Milan Broz
2012-12-30 13:19 ` Arno Wagner
2012-12-30 16:59 ` Emily Williams
2012-12-30 18:49 ` Matthias Schniedermeyer
2012-12-30 19:45 ` Arno Wagner
2012-12-31 6:37 ` Sven Eschenberg
2012-12-31 12:40 ` Richard
2012-12-27 20:29 ` Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121230105308.GA13288@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.